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

Run tests in module doc update #12245

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

brycegbrazen
Copy link

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)

brycegbrazen and others added 7 commits April 25, 2024 15:56
…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>
Signed-off-by: Bryce Gattis <bryce.gattis@brazenanimation.com>
@@ -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
Copy link
Member

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)

Copy link
Member

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?

Copy link
Member

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:

image

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?

Copy link
Author

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.

@nicoddemus
Copy link
Member

Would still likely to clarify if you can use globbing at all with when running a test for a specific module (the * operator)

pytest itself does not do any processing in that front, your shell does the * processing (as with any other tool).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants