-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Separate plugin tests from the core tests #4951
Conversation
Would it be a bad idea to shorten the path a little? ie test/plugin/... instead of test/plugin_tests/... (plugin singular!) I'm thinking of firing one particular test is a rather long path already currently we have
we would then get something like
|
We should really be encouraging people to use pytest, not the unittest module. Then it's easier to ignore. I'm not wedded to the directory name. In general I think more descriptive names are better, but if you feel strongly about it, I can change it. |
For now I'm still up to changing it, yes. I think it's descriptive that a directory plugin/ within a directory named test/ is referring to unittests :-) Question on the side: Please open an issue about updating the docs regarding pytest. I'll try to take care of it, but since I'm a noob around pytest still probably it would be good if you provide some basic info about it. Just some quick basiscs on how to run tests in quick words, I'll try to do the calligraphy then :-)) First question: How to run a single test with e.g. my example command above with pytest, but let's continue discussion about testing-docs in a separate issue and let's try to merge this one quickly. |
You literally just write the command |
@JOJ0 I just pushed the rename to just |
I was referring to: How to run single tests :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You forgot to change the imports to also use that new module name :-) Please go ahead and merge once that's done. Thanks!
Always something you miss lol |
Just wanted to express gratitude for doing this reorganization! Seems like a great idea. |
These references were out-of-date as of #4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
Seemed like a good first step for improving our testing |
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
These references were out-of-date as of beetbox#4951. Not sure why we were listing these individually in the first place; it's not like we want to be strict about docstrings in tests...
As discussed on Zulip, this refactors the plugin tests into a specific folder. This is a minor but important first step in increasing the test base and tidying everything up, and allows developers to exclude the plugin tests with ease.
There are no changes to actual tests, beyond anything relating to paths, and all tests succeed as they did before.