Facebook
Google
GitHub
Linkedin
test bench code
The first step is to consider what things should be tested and then what kinds of inputs should result in what kinds of outputs such that those outputs will likely only be correct if the thing being tested is correct.
For instance, if you have a lap (or 'split') feature, then you know that if the lap button is pressed at 0:13 that the displayed output should be 0:13 even three seconds later, but that if the lap button is then pressed again at 0:17 that the output should then say 0:20 three seconds after that.
Start with tests that verify the most basic functionality first and move to progressively more involved features.
This is something you should have been doing all along. Ideally, you would have defined the features you wanted your system to have, then defined the interface between the real world and your system, then developed your test benches, and only then start developing code. As you developed your code, each functional block that you implemented should have started out with a failing testbench before you started implementing that block.
By throwing all of the code together and then hoping to bolt on a testbench to it, you run the very real risk of having overlooked some subtle thing that could have been easily fixed had it been caught early, but that now might require reworking a large fraction of your project.
For instance, if you have a lap (or 'split') feature, then you know that if the lap button is pressed at 0:13 that the displayed output should be 0:13 even three seconds later, but that if the lap button is then pressed again at 0:17 that the output should then say 0:20 three seconds after that.
Start with tests that verify the most basic functionality first and move to progressively more involved features.
This is something you should have been doing all along. Ideally, you would have defined the features you wanted your system to have, then defined the interface between the real world and your system, then developed your test benches, and only then start developing code. As you developed your code, each functional block that you implemented should have started out with a failing testbench before you started implementing that block.
By throwing all of the code together and then hoping to bolt on a testbench to it, you run the very real risk of having overlooked some subtle thing that could have been easily fixed had it been caught early, but that now might require reworking a large fraction of your project.
