Add/Expose setup and teardown steps

Hi,

Coming from a (basic) usage of unittest, I think it would be nice if cocotb had some kind of setUp()/tearDown() handles available (as described here)

The target would be to provide a way for the user to add some code just before/after each tests (when it is needed to provide the same setup sequence, or to ensure that the design is set back to a known status after a test.)

Another couple of setup/teardown function could also be provided for the whole testsuite, being executed once before any test and once after the last test of the testsuite. This could be used to setup checkers using coroutines/threads and therefore avoiding:

• Polluting the beggining of every test
• Re-spawning coroutines/threads.

The first situation is probably relatively easy to implement, by adding something in the test decorator. The resulting code looking like :

if setup_function is not None : 
    setup_function(dut)
test_function(dut)
if teardown_function is not None :
    teardown_function(dut)

The second one might be a bit trickier, but working with the same principle. Something like (considering the full cocotb initialisation):

cocotb_init() # Iinitialize the simulator link, so we can read the design and are ready to go
if setup_function is not None : 
    setup_function(dut)
run_all_tests(dut)
if teardown_function is not None :
    teardown_function(dut)

From a user point of view, those functions should be visible on a global scope, to avoid using them multiple times. Something like:

def my_function(dut):
    cocotb.log.debug("Hey there ! Setup is ongoing !")
    cocotb.fork(my_checker(dut))

cocotb.set_test_setup(my_function)

@cocotb.test()
def test_my_unit_test(dut)
     # virtually call my_function(dut)
     # ...

Names could be:

• set_test_setup()
• set_test_teardown()
• set_global_setup()
• set_global_teardown()

Such setup/teardown could also be implemented on a TestFactory level, with the same kind of implementation.

[jonpovey]

So what about this for TestCases?

Keen for something approximately like this, haven’t spent time looking at good structuring for how these things get written. However… please all lowercase setup() and teardown()!

[suzizecat]

Had seemingly never saw the notification, but @ktbarrett proposition looks good to me. You might want to have the tests as proper member functions (with self) in order to easily share resources.

Nested testcases (with individual fast fails) would be great ! In example, having a root test-case with fast fail true, but the “leaf” test-cases without the fast fail would let the test-cases run until completion but stop the root test suite upon failure.