When and what to test in software development

Image courtesy of http://www.sxc.hu/photo/418215

I hear people around me often ask this question. Confused whether and when they should unit-test their classes, do integration tests on their components, functionally test their to be delivered software, and execute a regression test on their previously delivered product.

And really, there are a lot of answers to all these questions. And unfortunately, each of them are subject to the infamous answer of all questions in software development: It depends*.

But actually, there is a simple answer to all of these questions when you think about why you test things. Simple enough to give you food for thought. Tests reassure you that something (still) works. It gives you confidence. Confidence in the code that you write as a software developer. In the application that you deploy as a development team. In the product that you accept as a product owner/client.

Think about it. Think about your current project, and about what you currently test (or not) and why.
I often get the impression that people test, or want to test “because it is good for quality”. And it sure is. But think about what quality really is. Being confident about the solution that you built for your clients problem, and that you’ve delivered it well. That’s quality in a nutshell.

So actually the answer to the question “When and what to test in software development?” is really simple:

Test what gives you confidence about the (to be delivered) solution.

How you do it, is up to you.

Disclaimer: Some statements in this post may be over-simplified.

* actually, as in all of life, the universe, and everything, the answer should be 42. But that seemed a bit inappropriate in the context of this post.

Image courtesy of http://www.sxc.hu/photo/418215