HiveBrain v1.2.0
Get Started
← Back to all entries
snippetpythonMinor

Create and destroy object in Unit Test

Submitted by: @import:stackexchange-codereview··
0
Viewed 0 times
createtestandobjectdestroyunit

Problem

I have some doubt when I should create an object in an Unit Test when the object needs to be stopped cleanly.

Usecase:
I have a class ComplexClass which has 3 functions:

  • Start(): starts a Thread



  • Stop(): stops the thread



  • GetX(): which gets a value



When I test this class I want to check if GetX() returns 42, but first I have to start the thread, and after it I want to stop the Thread. (During testing I don't want many dangling threads running).

Are fixtures the way to do this?:

class TestComplexClass(object):
    @pytest.fixture()
    def complexclass(self, request):
        print ("[setup] ComplexClass")

        cc = ComplexClass()
        def fin():
            print ("[teardown] ComplexClass")
            cc.stop()
        request.addfinalizer(fin)
        return cc

    def test_GetX(self, complexclass):
        // do some stuff

        complexclass.start()
        assert complexclass.GetX() == 42, "GetX() should return 42"


Or should I create the object in the Unit Test?:

class TestComplexClass(object):
    def test_GetX(self, complexclass):
        // do some stuff

        cc = ComplexClass()
        try:
            cc.start()
            assert cc.GetX() == 42, "GetX() should return 42"
        except AssertionError:
            cc.stop
            raise


(Note I'm using Py.Test)

Solution

This somewhat depends on which principle you value higher. Small repetition:

F.I.R.S.T

F: Fast

Pretty self-explaining. Unit tests have to be as fast as possible for TDD to be viable.

I: Independent

Unit tests are not depending on anything else than the testing-framework and the class under test (cut). Not even on other tests. Unit tests prepare their own data and setup and clean up after themselves after evaluation. It must not matter in which order unit tests are executed!

R: Repeatable

Unit tests give the same result when they are repeatedly executed. Even on a new moon with low tide. They always look for the same results and perform the same operations.

S: Self-Validating

Unit tests validate the result of any operation themselves. They may not give any results to external classes for validation. Also they should be self-explaining as to why that result is expected.

T: Timely

Unit tests are to be written as close as possible before the implementation of a feature

principles freely adapted from Agile in a Flash

In this case you will have to evaluate the fast principle against the independent principle
It will definitely be faster to create the instance of ComplexClass only once (on fixture setup), but that will undermine the independency of unit tests and may will cause problems when you depend on execution order.

Context

StackExchange Code Review Q#44676, answer score: 5

Revisions (0)

No revisions yet.