2 ms·
More testing can help show the uncertain requirements in more concrete ways. What should happen in these cases? Now we have this list in one place does it seem
by IanCal 2y ago
More testing can help show the uncertain requirements in more concrete ways.
What should happen in these cases? Now we have this list in one place does it seem unusual or inconsistent?
Bonus points if you can have more general tests (like property based ones) that let you test broader statements.
I always fall back to this example but I built a testing lib for a stack we had a UI framework in. It helped because we could write a test like:
"For any UI, if the user moves right and the focus changes then when the user moves left the focus goes back to the original item"
And then we found a bug in the spec with:
For any series of API calls that build a UI, and any series of user interactions, one of the following is always true
* There are no items in the UI
* There is exactly one item with focus
Being able to specify things at this level resulted in us being able to define the major behaviours succinctly and that made it easier to have them be consistent.
- Nemi 2y agoI see the parent commenters point as being more of the “can’t see the forest for the trees” type of uncertain requirements. To go into more detail, it is the type of uncertainty about whether you are actually solving the right problem or if it really is a problem. While what you suggest does help ferret this out, what you are suggesting can also prolong the process of getting the code in front of a real end user to see if they use or adopt it the way you are expecting. It allows you to quickly throw away ALL the code and get to solving the right problem. Another way to put it, the more the problem space is unknown, the faster you should get the code in front of someone and delay the edge-case discoveries.