nose fixture reference

I’m going to cover nose setup and teardown fixtures at the package, module, class, method, and function level.
This isn’t about what code to put into the fixtures, just about the syntax and flow.
And a bit about naming conventions.

Although I talked about the fixtures in the nose introduction, I think this post will work better as a reference.

Contents

Method vs. function

In the discussion below, I’m distinguishing a difference between method and function.
I’m following a convention from the python documentation:

In other words, if a function is NOT in a class, it’s a function.
If it IS in a class, it’s a method.

Package level fixtures

Add ‘setup_package()’ and ‘teardown_package()’ functions to the ‘__init__.py’ of a package.
‘setup_package’ will run before any test modules within the package.
‘teardown_package’ will run after all of the modules are run (if setup succeeded).

Module level fixtures

Module fixtures bracket the execution of everthing in the module (test classes and test functions).
These functions only run once each.

Class level fixtures

Class fixtures bracket the execution of everthing in a class.
These functions only run once each.

Class method level fixtures

Class method fixtures bracket the execution of each and every test method in the class.
These functions run multiple times, once for each test method.

Function level fixtures

Function level fixtures are the oddball of the bunch.
Nose doesn’t do any naming convention detection for this.
It’s all done with the ‘@with_setup’ decorator, which has to be included from ‘nose.tools’.

This does allow you to have different fixtures for different tests.

However, please choose names that make sense.
It also allows you to forget to add the decorator, so be careful.

Full example

__init__.py

test_using_classes.py

test_using_functions.py

Control flow

I put the files in a testNoseFixtures directory.
Running the tests with -s so I can see the output, produces the following.

Alternative names

Nose is pretty forgiving about naming conventions for fixtures.
I’ll list the alternative names for the different fixtures.
However, I strongly encourage you to use the names listed above.
The names listed above are, my opinion, easiest to read.
The exception to this is setup_function/teardown_function, since those are possibly custom for every test function, use whatever you like.

setup_package
setup, setUp, or setUpPackage
teardown_package
teardown, tearDown, or tearDownPackage
setup_module
setup, setUp, or setUpModule
teardown_module
teardown, tearDown, or tearDownModule
setup_class
setupClass, setUpClass, setupAll, or setUpAll
teardown_class
teardownClass, tearDownClass, teardownAll, or tearDownAll.
setup (class method fixtures)
setUp
teardown (class method fixtures)
tearDown
setup_function / teardown_function
can be named anything, since it’s attached to a function with ‘@with_setup’

If you like this…

Get notified of new posts, delivered to your inbox. No spam. Not very frequent.

Comments

  1. says

    Brian, I’m interested to hear if you think py.test Dependency Injection through funargs brings benefits over nose? From their docs:

    “The basic mechanism for injecting objects is also called the funcarg mechanism because objects are ultimately injected by calling a test function with it as an argument. Unlike the classical xUnit approach funcargs relate more to Dependency Injection because they help to de-couple test code from objects required for them to execute.”

    Looking through your nose reference here (nice and simple, BTW!), it feels like I can have 100% decoupled test code, using the with_setup() method you’re using here.

    • says

      I think the pytest treatment of fixtures and resources is exceedingly cool. However, it’s a bit hard to grok at first. This is next on my list of stuff to write about.
      I’d be particularly interested in knowing what type of situation or resource you are using that nose fixtures just don’t quite cut it.

      • says

        I think I’m realizing that nose fixtures do cut it, and don’t see anything that’s very complex at all. I really just landed at py.test first. I’m currently moving from vanilla Django TestCase, and a mix of a) repetitive code in setUp() methods, and b) finicky JSON fixtures, supported by TestCase.

        I also agree that they’ve been a little hard to understand, but the thought of “explicit, modular, scalable” was enough to push me through that :)

        PS: There’s an interesting post written yesterday by Ned Batchelder (http://nedbatchelder.com/blog/201311/adhoc_data_breakpoints.html), wherein he debugs a strange issue with nose. In the comments, Brandon Rhodes says he moved away from nose for the same issue. Curious about your thoughts on that (including my comment there).

        Thanks!

Leave a Reply