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

Output verbosity for test cases #11639

Closed
plannigan opened this issue Nov 25, 2023 · 0 comments
Closed

Output verbosity for test cases #11639

plannigan opened this issue Nov 25, 2023 · 0 comments
Labels
topic: config related to config handling, argument parsing and config file topic: reporting related to terminal output and user-facing messages and errors type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@plannigan
Copy link
Contributor

This is a follow on to fine-grained output verbosity for assertions (#11387/#11473). The next "category" that seems to stand out based on the current behavior is how pytest displays test cases are it executes them. By this I mean the distinction between:

--quiet

................................................................................. [  2%]
................................................................................. [  4%]
<truncated>

vs

default

testing/acceptance_test.py .....                                                  [  0%]
testing/deprecated_test.py ..........                                             [  0%]
testing/test_argcomplete.py ..                                                    [  0%]
<truncated>

vs

--verbose

testing/acceptance_test.py::TestGeneralUsage::test_docstring_on_hookspec PASSED [  0%]
testing/acceptance_test.py::TestInvocationVariants::test_invoke_with_invalid_type PASSED [  0%]
testing/acceptance_test.py::TestInvocationVariants::test_invoke_plugin_api PASSED [  0%]
testing/acceptance_test.py::TestInvocationVariants::test_core_backward_compatibility PASSED [  0%]
<truncated>

Additionally, I think this would also extend to the output of --collect-only (doesn't show all of the states):

--quiet --quiet

testing/_py/test_local.py: 183
testing/acceptance_test.py: 84
testing/code/test_code.py: 17
<truncated>

vs

default

testing/acceptance_test.py::TestGeneralUsage::test_docstring_on_hookspec
testing/acceptance_test.py::TestInvocationVariants::test_invoke_with_invalid_type
testing/acceptance_test.py::TestInvocationVariants::test_invoke_plugin_api
testing/acceptance_test.py::TestInvocationVariants::test_core_backward_compatibility
<truncated>

There doesn't seem to be an existing name for this, so I plan to start the work using test_case. If someone comes up with a better name, I'd be happy to use that. I don't think there would be anything else that would fit into this "category". But feel free to bring things to my attention if I missed something.

@Zac-HD Zac-HD added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature topic: reporting related to terminal output and user-facing messages and errors topic: config related to config handling, argument parsing and config file labels Nov 27, 2023
flying-sheep pushed a commit to flying-sheep/pytest that referenced this issue Apr 9, 2024
Allow for the output of test case execution to be controlled independently from the application verbosity level. 

`verbosity_test_case` is the new ini setting to adjust this functionality.

Fix pytest-dev#11639
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: config related to config handling, argument parsing and config file topic: reporting related to terminal output and user-facing messages and errors type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

2 participants