Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test collection is ~50x slower when project root dir is specified #4873

Closed
yozlet opened this issue Mar 1, 2019 · 4 comments
Closed

Test collection is ~50x slower when project root dir is specified #4873

yozlet opened this issue Mar 1, 2019 · 4 comments
Labels
topic: collection related to the collection phase type: question general question, might be closed after 2 weeks of inactivity

Comments

@yozlet
Copy link

yozlet commented Mar 1, 2019

Compare: both of these commands are run in my project root dir, differ only by whether the path to that root dir is explicit or implicit, yet the second one takes 50x longer.

$ python -m pytest --collect-only                                                           at 2019-03-01 13:54:32
=============================================== test session starts ===============================================
platform darwin -- Python 3.6.8, pytest-4.3.0, py-1.8.0, pluggy-0.9.0
Django settings: $PROJECT_NAME.settings.pytest (from ini file)
rootdir: /Users/yoz/$PROJECT_NAME, inifile: pytest.ini
plugins: mock-1.10.1, metadata-1.8.0, jest-0.3.0, django-3.4.8, cov-2.6.1
collected 333 items

[ output skipped ]

========================================== no tests ran in 1.87 seconds ===========================================
$ python -m pytest --collect-only .                                                     at 2019-03-01 13:52:56
=============================================== test session starts ===============================================
platform darwin -- Python 3.6.8, pytest-4.3.0, py-1.8.0, pluggy-0.9.0
Django settings: $PROJECT_NAME.settings.pytest (from ini file)
rootdir: /Users/yoz/$PROJECT_NAME, inifile: pytest.ini
plugins: mock-1.10.1, metadata-1.8.0, jest-0.3.0, django-3.4.8, cov-2.6.1
collected 333 items

[ output skipped ]

========================================== no tests ran in 83.55 seconds ==========================================

I've done this multiple times, so I'm fairly sure it's not a cache issue.

If it's any help: this is running in a pipenv-run virtualenv inside a conda environment (yes, this is suboptimal).

@yozlet
Copy link
Author

yozlet commented Mar 1, 2019

I think this has something to do with not properly using pytest.ini, even though it lists the file in output. When I comment out the testpaths setting that lists the subdirs containing tests, both commands take roughly the same time and the Package tags in the output are alphabetically ordered, rather than following the order in the testpaths configuration.

Note, however, that pytest --trace-config produces identical output (other than memory locations) for both, which isn't helpful.

@nicoddemus
Copy link
Member

Hi @yozlet,

This is actually the expected behavior, the docs for testpaths say:

Sets list of directories that should be searched for tests when no specific directories, files or test ids are given in the command line

So by passing ., you are skipping testpaths, which is intentional. 👍

@nicoddemus nicoddemus added type: question general question, might be closed after 2 weeks of inactivity topic: collection related to the collection phase labels Mar 1, 2019
@blueyed
Copy link
Contributor

blueyed commented Mar 1, 2019

Yeah, apparently not really an issue.

But maybe we could include testpaths in the header, next to rootdir/inifile?

That would at least show a diff in the outputs above.

@nicoddemus
Copy link
Member

Sure, created a new issue for it.

@yozlet I'm closing this for now, but feel free to followup with further questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: collection related to the collection phase type: question general question, might be closed after 2 weeks of inactivity
Projects
None yet
Development

No branches or pull requests

3 participants