You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the states are known and the inputs are known it's possible to generate a list of all of the possible scenarios that the state machine is supposed to handle. It's reasonable to say that each of these must have at least one unit test.
A library can generate a TestCase (or a mixin or something) that defines one test for each of these cases and gives them failing implementations that need to be overridden. This will give developers a very easy way to know the minimum set of tests they still haven't written.
Possibly there's a better interface than "a thing you can subclass" for this - but it's not immediately obvious to me since the way unittest works is pretty firmly "subclass this thing". (But... like... a class decorator maybe?)
The text was updated successfully, but these errors were encountered:
Perhaps an alternative to subclassing is a class decorator which inspects the decorated class and adds new failing tests for any transitions that appear not to be tested. As with the subclassing idea, this would involve a particular naming convention for test methods so the decorator could accurately determine which cases had tests written for them.
Since the states are known and the inputs are known it's possible to generate a list of all of the possible scenarios that the state machine is supposed to handle. It's reasonable to say that each of these must have at least one unit test.
A library can generate a TestCase (or a mixin or something) that defines one test for each of these cases and gives them failing implementations that need to be overridden. This will give developers a very easy way to know the minimum set of tests they still haven't written.
Possibly there's a better interface than "a thing you can subclass" for this - but it's not immediately obvious to me since the way unittest works is pretty firmly "subclass this thing". (But... like... a class decorator maybe?)
The text was updated successfully, but these errors were encountered: