Other nose/intro

Table Of Contents

Previous topic

Testing Code With Nose

Next topic

Using Test Attributes

This Page

Daya Bay Links

Content Skeleton

Nosetests Introduction

Many presentations are available describing how to create nosetests, doc:3645 is recommended starting point for the absolute beginner. Also wiki:Unit_Tests provides an excellent introduction.

Unit Testing Philosophy

The benefits from unit (class level) testing come principally when testing development takes place together with (and informs) interface design/development. By thinking first of how to test (rather than how to implement) you are more likely to end up with quality code.

Because of this retro-unit testing once the interface has solidified is not useful, except as a way to document and fix bugs.

Unit tests should not be complicated, as when they fail you (and others not familiar with the code) want to be able to understand why quickly.


Many of the packages of NuWa include a tests directory with nosetests named test_<something>.py. This plethora of examples using many different styles can make it difficult to decide which is the appropriate approach to follow. Thus the below provides some guidelines to the testing done in a few packages.


Large numbers of tests at all levels, the shorter ones make good beginner examples. Such as:


test_calibpmtfinegain.py makes good use generative nosetests allowing separate tests for every validity record in a table to be generated via the yield of check functions. Note that for testing from the main have to interate over the test in order to get the check functions and their arguments. Other packages are easier to follow if you are new to nosetesting.


Mostly deals with testing the internals of DBI. Typically testing would not need to descend to these levels.


short and focussed

Individual tests and test modules should be kept short and focussed. The motivation being that when a test fails it is advantageous to be able to work out what went wrong quickly without having to debug a complicated morass of code.

Also as running:

nosetests -v

will run all def test_<name>: functions from all test_<modulename>.py modules in the tests directory so there is no cost to splitting tests as much as practical.

dont repeat yourself

Common functionalty should not be repeated in multiple test modules. Instead import the classes and functions from other python modules. The examples often do this from a common cnf.py module.

Zero Cost Test Development

A simple concrete development style example of how to develop and test a python class in a manner that creates tests with almost no overhead.

  1. implement single Name classes within single name.py files and make them executable:

    svn ps svn:executable yes name.py    # set SVN property to make executable everywhere
  2. run the __main__ block:

  3. as each feature is added to a class test it within the __main__ block:

    if __name__ == '__main__':
        obj = Whatever()
        assert ...
  4. once the feature is working, copy the __main__ into a test named after the feature:

    def test_feature_A():
        obj = Whatever()
        assert obj.whatever == smth
  5. once done with a class move the tests over to a test_name.py file that lives within a tests directory


doc:6280 : Encouraging Nose Testing

Make adding tests a zero step process

doc:5258 : Your NuWa Testing System

Guide to running and creating tests within nose based testing system, allowing NuWa behaviour to be contrained to fulfil the expectations of package experts.

doc:3645 : NuWa Offline Software Testing System

Demonstrating the ease and usefulness of our software testing system, with the desire to increase its usage.

doc:3091 : NuWa-Trac and Testing System

Guide to using NuWa-Trac, creating and modifying tickets and running tests, developer guide to adding tests.