-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Run tests in module doc update #12245
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
base: main
Are you sure you want to change the base?
Run tests in module doc update #12245
Conversation
…or new users Signed-off-by: Bryce Gattis <bryce.gattis@brazenanimation.com>
Signed-off-by: Bryce Gattis <bryce.gattis@brazenanimation.com>
Signed-off-by: Bryce Gattis <bryce.gattis@brazenanimation.com>
Signed-off-by: Bryce Gattis <bryce.gattis@brazenanimation.com>
…rycegbrazen/pytest into run_tests_in_module_doc_update
@@ -26,6 +26,11 @@ Pytest supports several ways to run and select tests from the command-line or fr | |||
|
|||
pytest test_mod.py | |||
|
|||
When passing a path as a positional argument, pytest does not recursively |
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.
IMHO this is a bit verbose, I think it is enough to mention that the user can pass the absolute or relative path to the test file.
Something like this:
**Run tests in a module**
You can pass the relative or the absolute path to a test module directly:
.. code-block:: bash
pytest test_mod.py
I don't feel the need to mention that pytest will not look for test_mod.py
recursively, few tools work like that (without a separate flag that is).
(I would leave a suggestion but GH does not let me place a suggestion outside the diff)
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.
@The-Compiler, which teaches pytest for a living, is this something users in general get confused about?
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.
I don't think this ever came up, no. FWIW, here is the slide I have for it:
I agree that it's not really the job of the pytest documentation to explain this in detail. There's nothing special about pytest here, any other tool that takes a file name would work the exact same way.
@brycegbrazen can you elaborate a bit on why you think this is necessary, or why you would consider that pytest would do anything like this in the first place?
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.
Hi all thanks for the feedback.
I'm migrating a repo from using unittest
to pytest
and the test discovery code pattern I was using was *
by default, and then <basename>.py
if I wanted to run one specific file's tests.
Looking at the unittest
documentation though, it seems they definitely are built off of the assumption that you will use the '*' operator (as the default value for example is test*.py
).
So perhaps my assumptions about how things would work are biased coming from unittest
.
I agree my pass was a bit verbose. Perhaps something shorter like:
**Run tests in a module**
You can pass the relative or the absolute path to a test module directly:
.. code-block:: bash
pytest test_mod.py
Note that pytest has no special handling for the '*' operator.
pytest itself does not do any processing in that front, your shell does the |
Add a bit of additional information about running tests in a module for new users.
TODO:
Would still likely to clarify if you can use globbing at all with when running a test for a specific module (the * operator)