Struggling to introduce TDD or Acceptance Testing? Here’s a really powerful simple first step that you can perform immediately – How to get your development teams “thinking” about tests and how to test with little or no negative impact and a few seconds setup time.
This assumes you’ve already broken out your story/feature/activity into developer-sized tasks.
- Push the keyboard away and get a sheet of A4 or Letter paper and a pen or pencil.
- Draw 2 lines to Divide the paper into 3 roughly similar sized areas.
- Pair up with the developer who’s going to work on a task.
- Start a timer – you have 10 minutes.
- Spend 3 minutes listing out as many “pass” cases as you can think of between you – all those simple “happy path” things.
- Spend 3 minutes listing out as many “fail” cases as you can think of – bad inputs, exceptions etc.
- Spend 4 minutes thinking of all the boundary cases you can think of – e.g. date/time/time zone, rounding, location etc. Often these boundaries depend on your problem domain.
- That’s it – you’re done!
OK, this isn’t going to give you perfect code and it does take a bit of practice. Try not to agonize too much about whether these are unit, functional or acceptance tests for now. We’re still learning to fly here.
Much as standing up collaborating at a whiteboard uses a different part of your brain to coding; paring up, brainstorming and writing with a good old pencil & paper does a similar job. The discipline of not touching the code for a short period of time and thinking about how you’re going to test and what could go right or wrong will significantly improve the quality of what you produce – it usually makes the coding easier too.
Better still – you should now have your first unit tests to write! – pick the simplest ones you have on there and get them working! (I usually start with input validation. I know it’s not directly related to end user value but once I get a good grasp on inputs the rest fits in my head more easily.)