Testing makes feedback easier

Always be adding tests for faster feedback.

We always need feedback on our work. Is it the right colour, tone of voice, does it work as expected? Plus many more questions too. For much of life, in-person feedback is fine, and preferred: is the person I’m talking to looking happy/sad at what I’m saying? Are the customers looking happy with the food? Are the students looking perplexed with the materials, or doing something unexpected?

For software development testing often has its own phase in the life-cycle. This might suggest that testing can be handed off to another group of people, after development is done. This, of course, is wrong. Testing should be happening from before development is started. Acceptance tests should be considered, and planned along with the initial discussions about the software. Unit tests should be written as the development is happening too.

This is to say that testing should be a whole team effort. The feedback the tests provide are essential to building something that does what it should do.

Tests tell us that the method, variable, is correct. They tell us that our refactoring is successful. They provide the safety net for our work. This is the way.

I was reminded of this recently while working my way through my book collection: picking up and reading books that have been on the shelf too long without being read. I was looking for something and found this in Testing Extreme Programming.

Automate your tests

To gain the most from tests they should be automated. Lisa Crispen and Tip House, explain it clearly in Testing Extreme Programming as you can see in the photo.

Chapter 20 goes into great detail why manual tests are wrong for development. They take long, they are unreliable, and you probably cut them when pressed for time. Do you really want to repeated test the inputs on an interface form for logging in, when you could easily automate it to run in a few seconds?

You are better to put the time in to put automated tests into place and then used the time gained to improve the quality of your work.

Teach people test automation

Teach your people to write automated tests. This is the way. You can ensure all the steps are covered, and not forget one.

Start small with automated unit testing, and then integration as part of commits.

Testing also works well with pairing and ensemble work as people learn more about the code base.

Then keep adding more tests as you add more components.

This is the way.

Your people will thank you later as they produce higher quality code.

By the way, go read any of Lisa’s newer books. While Testing Extreme Programming is a good intro to testing and xp in general, her newer books are probably more useful. I know that I found them useful on the whole-team approach.

---