When we’re unit testing, we focus on the scenario we want to test, and then write that unit test.
Pretty simple, right?
That’s how are are minds work. we can’t focus on many things at the same time.
TDD acknowledges that and its incremental nature is built around it.
TDD or not, when we have a passing unit test, we should do an evaluation. How good are our unit tests? The following series is on attributes of good unit tests.
Start with this table:
|
Property
|
Description
|
| Validity | Does the unit test check a valid scenario? Is this scenario always valid? |
| Readability | Of course I understand the unit test now, but will someone else understand the unit test a year from now? |
| Speed | How quickly does the unit test run? Will the unit test slow down an entire suite? |
| Accuracy | When the unit test fails, can I easily find the problem is in the code, or do I need to debug? |
| Differentiation | How is this unit test case different from its brothers? Can I understand just by looking at the tests? |
| Maintenance | How much work will I need to do around this unit test when requirements change? How fragile is it? |
| Footprint | Does the unit test clean after itself? Or does it leave files, registry handles, threads, data or a memory blobs that can affect other unit tests? |
| Truthiness |
How much of the code is really executed? Would this unit test report true, while hiding a real problem? |
| Deterministic | Does this unit test have dependencies (the computer clock, CPU, files, data) that can alter its result based on when or where it runs? |
| Isolation | Does the unit test rely on a state that was not specified explicitly in it? If not, will the implicit state always be true? |
If something’s not up to your standards (I’m assuming you’re a high standard professional) fix it.
Now, I hear you asking: Do all this for every unit test?
Let’s put it this way: If the unit test fails the evaluation, there’s going to be work later to fix it. When would you rather do it – now, when the unit test is fresh in your head, or later, when you have to dive in again, into code that you haven’t seen in 6 months, instead of working on the new exciting feature you want to work on?
It’s testing economics 101. Do it now.
Update: I’ve removed robustness (since it’s close to Maintenance) and added Truthiness.
For training and coaching on topics like this, contact me.
0 Comments