Make tests more resistant

[lekcyjna123]

Today I am trying to introduce not backward compatible changes in layouts on main pipeline (change register id to tuple with register id and register type). Changes in production code were easy and straight forward, because it was enough to modify common layout and places that used old values. On the other hand changes in tests are painful because every test have to be edited manually. In each test file there are its own input data generators, so the same modification have to be introduced in many places. Additionally there is a lot of different ways (e.g. ad hoc framework in SchedulerTests, tests using internal knowledge of RS, tests using only module interfaces...) to write tests so each file has to be considered separately.

Main issues:

• duplication of input data generators
• different testing ways

This issue is mainly created to don't forgive about that problem and take it into consideration when new test framework will be created.

[Kristopher38]

duplication of input data generators

This is something that I've noticed while having to modify tests for some FUs - I wanted extra functionality for a particular FU but I didn't want to let go of the input generator that we have in the abstracted FU testing "framework". I guess there's a clear need to generalize input generators.

different testing ways

There are two kinds of tests (broadly):

• making sure internal state is correct (which I'm not a great fan of)
• making sure the observable effects are what they should be

Also orthogonal to these are tests which have:

• randomized inputs
• inputs chosen by hand

We should make sure to take all of them into account.

[lekcyjna123]

I would like to be able to:

• said that in given cycle, a pair of input signals can not have the same value (to test multiport modules)
• defer update of python structs to the end of current cycle