snippetpythonMinor
Create and destroy object in Unit Test
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:
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?:
Or should I create the object in the Unit Test?:
(Note I'm using Py.Test)
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
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.