proper way of dividing tests in subtests in nosetests

Question

I have an object that I build up in an iterative way. I want to test every single step. Here's a bad test function for that:

def test_object:
    o = object.Object()
    o.step1()  # in place method
    assert(o.step1property)
    o.step2()  # in place method
    assert(o.step2property)
    o.step3()  # in place method
    # ...

So, after every step, I check whether the object has some desired properties that should be there. I can split this into subtests by using the yield keyword, like:

def test_object:
    o = object.Object()
    yield o.step1
    assert(o.step1property)
    yield o.step2
    # ...

At this point you may ask: why not put these calls in separate tests? If they need the correct output of the previous result, put that one in a .pickle file and make it independent. And I generally agree. However, I have a use case where that's not very helpful: Let's say step1() initializes the class, and step2() is a JSON export. Then I need to make sure that the JSON export always works even when I change stuff in step1(). Relying on .pickle files would be dangerous, since they could be outdated, and the JSON export could pass when in fact it fails with my newest objects. I could separate the assertions in two separate tests and run step1() twice (once in its own test and once in a setup method for test 2), but step1() is very time consuming.

What is the preferred way of doing this? Is there a way to call "subtests" other than yield, and can I get the return value of those subtests? In my case, I'd love to have the JSON string since I am saving all test results to an output directory, and I want to pass the string to the write_to_output_dir function (if this is bad design, please tell me!).

Answer 1

If a class is hard to test like this, there is a good chance you did something less than optimal in your object-oriented design. Have a look at this tech talk on unit testing if you can spare the time. It also deals with good (as in testable) OO design.

tl;dr essentially, it is good practice to make your unit tests as atomic as possible. Furthermore, you can mock unrelated functionality, that is not being tested in a particular unit test.

To focus on your example: you want to check the initialization independently. It is a sort of factory, I presume. Then you have a method to export to JSON. This is probably the point, where you want to mock your initialized object and test the JSON export on this mock. That said, the JSON exporter should probably also be a separate class to avoid mixing initialization with operational logic. Once you refactor the code, you might find it much easier to test it.