Test first - Requirements and Edge Cases
Imagine you got a story to solve in the system you are working on. What’s your immediate reaction?
If you’re thinking about how to test it, you’re on your way to fame and glory!
Well, not fame, or glory. At least restful nights or even time to work on other things.
Another thing about thinking in “test first” - you think about requirements in a different manner.
You could think:
- how would this requirement “happen” in the system?
- how would I simulate the requirement in the test system?
- how would this requirement fit properly with all the past requirements?
The last one is essential.
As the system grows, more and more requirements accumulate along with their implementation.
- How can the team keep track of current and past requirements?
- All the situations where requirements are conflict with each other?
- What if a new requirement conflict with a past one in a particular situation?
- How about all the edge cases?
Testing after coding will cover the first two, because the requirements specify them. Following the requirements will naturally generate tests.
Manual testing that is thorough will get case three.
It’s case four: edge cases - well, testing after coding almost never exposes those in development. Thorough manual testing on integration will get some edge cases. Do you know how you will find those edge cases?
Production
Yes, production.
Those edge cases will appear in production and you will have to decide how to deal with them quickly!
Requirements specify the happy path. Edge cases depend on implementation and you have a better chance of finding those by testing first.
When you code first - these are common statements I hear:
- “There will always be a value for this”
- “That will never be null”
- “The input type will always be that type”
When I test first and I create a function - I always create a test for these cases. Why?
Then I can decide right there a logical and consistent course of action in a calm manner, where I can consult with teammates, take time to think, etc.
Test first - it makes you think about requirements and edge cases better than testing second (or not even at all…)