How to investigate pytest-warnings

We recently integrated pytest, a Pythonic test runner, with our framework. After the tests were executed, pytest threw a couple of warnings.
We decided to share our findings as the Google search results to debug the pytest-warnings were not quite revealing.
Solution: Use thepy.test -r wcommand to gather additional information about the warnings.

Reporting in pytest:

The py.test command runs the tests and displays a test summary. For a more comprehensive report use the -r reporting command line option with pytest.
The -r option can be used to show some extra summary specified by the character following it.

  -r chars              show extra test summary info as specified by chars
                        (f)ailed, (E)error, (s)skipped, (x)failed, (X)passed
                        (w)pytest-warnings (p)passed, (P)passed with output,
                        (a)all except pP.

So if you were interested in investigating only failures, use -r f as a command line parameter.

What triggered those pytest-warnings?

When you run the py.test command, pytest scours through the root directory and its sub-directories looking for files:
a. Test files start with test_*.py or end with *
b. Test classes prefixed with Test that have no __init__ method
c. Test functions prefixed with test_
pytest ignores files that has a class with a __init__method in them but it responsibly throws a warning about ignoring the file when it follows the pytest naming convention. In our case, we have two files in our framework that begin with Test_ but have __init__ method in them. Mystery solved!

Now that you know how to read through the pytest-warnings try out the other command line options in pytest. Use the py.test -h command to know the list of command line options available.

If you liked this article, learn more about Qxf2’s testing services for startups.

Shivahari P

I help engineer high quality software. I started out as a manual tester at Cognizant Technology Solutions where I worked on a healthcare project. I grew bored of highly scripted testing that required me to turn off my brain and blindly execute test cases from a document. I quit and decided to try freelancing as a trainer. I mentored aspiring engineers on employability skills for a while. I liked exploring applications as a hobby and was always on the lookout for better testing jobs. I found Qxf2 had a better balance of exploratory testing, scripted testing and automation and decided to join them. I like football and economics.

One Comment

Leave a Reply

Your email address will not be published.