In my experiences, 95% of the test cases we write are read and executed only by ourselves. If we generally target ourselves as the audience, we should strive…
…to write the least possible to remember the test.
I like the term “test case fragment” for this. I heard it in my Rapid Software Testing class. On the 5% chance someone asks us about a particular test, we should be able to confidently translate our chicken scratches into a detailed test. That’s my target.
If we agree with the above, couldn’t we improve our efficiency even more by coming up with some type of test case short hand?
- Instead of “Expected Results”, I write… “E:”.
- Instead of writing statements like “the user who cancelled their order, blocks the user who logged in first”, I prefer to assign variables, “UserA blocks UserB”.
- Instead of multiple steps, I prefer one step test cases. To get there I make some shortcuts.
- Rather than specifying how to get to the start condition (e.g., find existing data vs. create data), I prefer the flexibility of word “with” as in “With a pending order”. How the order becomes pending is not important for this test.
- To quickly remember the spirit of the test, I prefer state-action-expected as in “With a pending order, delete the ordered product. E: user message indicates product no longer exists.”
- Deliberately vague is good enough. When I don’t have enough information to plug in state-action-expected, I capture the vague notion of the test, as in “Attempt to corrupt an order.”. In that case I drop the “E:” because it is understood, right? Expected Result: corruption handled gracefully.
It may be a stretch to call these examples “shorthand”, but I think you get the idea.
What test case short hand do you use?
Labels: writing tests