NetBeans Screenshot of the Week #40: Python Test Runner UI

In the 7.0 builds, we have a dedicated unit test runner for Python now. Running a file as a test, or running the test project action, will open a test runner with the output docked on its right hand side, instead of just the output window (click for full size screenshot):

Here's the test runner itself:

What you want to see in the output is a single green line which says "All n Tests Passed", where n is hopefully a large number. But when one or more of the tests fail, you see something like the above. Running the Next Error action (Cmd-.) will jump to the next failed test, just like it normally jumps to the next error in the current output window, or the next task in the tasklist.

One thing to notice (and this is new in 7.0) is that we now include the failure message right there in the test summary for each test, so you don't have to drill into an individual test to see the failure message. You can also hover over a test and any output from that test is shown in a tooltip. You can also right click on tests and select "Run Again" to run just one specific test over again.

This is the same window as the one we have for Ruby. In fact, Erno, who wrote the Ruby test runner, has modularized the code now such that it's the same implementation for both languages - we just have language specific plugins to actually hook into the various testing frameworks. Currently, for Python we support the two builtin testing frameworks: unittest and doctest. The above screenshot showed a regular unittest run. Here's a doctest:

One important thing to note is that you don't have to instrument your code with any test running code. As long as you place doctests in your docstrings, or as long as you have any classes extending unittest.TestCase, the test runner will find them. All you have to do is run Test Project:

and when you have done that, both unittests and doctests are found and included in the same test run - here's both failing doctests and unit tests:

Once again, kudos to Erno for writing the excellent test runner support! And as usual, let us know of any problems.

P.S. Jean-Yves Mengant has also done some excellent work recently. In addition to some cool new quickfixes in the Python editor for NetBeans, he has just integrated a multithreaded debugger for Python!


Where can I download the binary for Python Netbean 7.0 for Windows platform? Currently I download the Python Netbean from the hudson build. Is it the same place for me to download the python Netbean build?
I haven't tried the latest build. But the previous release with unittest and code coverage is really awesome. It is really useful for me. Just one problem with me with previous build is when running unittest, it will complain the cannot import my test file. For eg, I am testing c:\\work\\ I must added c:\\work into the python path in order to run the unit test. If I had another file at c:\\work\\common\\, I will need to add c:\\work\\common into python path also. This is a bit annoying but I can live with that.
Thanks for the great work on the best IDE!

Posted by shin guey on January 05, 2009 at 09:34 AM PST #

Hi Shin,
thanks for the comment. Yes,

is the right place to get the latest Python bits, including for Windows. We'll have proper installers etc. built for the full release when we get to beta, rc1 and final.

I'm not sure I fully understand your problem. You -do- have to have all the test files part of your project (e.g. under one of the source directories listed in your source file roots, listed in your project properties dialog (right click on the project in the project explorer)). Is that the problem? Or are you saying there is a problem accessing files in packages?

If you can boil this down to a simple self contained project which demonstrates the problem, and file it as a bug report, that would be great:

Posted by Tor Norbye on January 05, 2009 at 11:07 AM PST #

Based on the explanation of how the testrunner works it seems it is currently not possible to run standalone doctests? What I mean with this is to test separate \*.txt files with doctests.

The testrunner that I am familiar with solves this by letting you specifiy a function (suite) within your test modules. This function is called and is supposed to return a unittest.TestSuite instance.

That means you can have code like:

def suite():
s = unittest.TestSuite()

Posted by Jeroen on January 23, 2009 at 10:48 PM PST #

Post a Comment:
Comments are closed for this entry.

Tor Norbye


« July 2016