Lately I’ve been thinking about testing, so in this series I want to talk about how I approach testing and some of my personal philosophy. I intend to focus on what I believe it takes to make tests work as part of a robust development process.

Carrying on the testing theme, in this article I’m going to describe “the test pyramid”. The test pyramid is a way of thinking about how tests relate to one another - and how they support building quality software.

In this part of my “On Testing” series I talk about what I believe the goals of automated testing are, and how they influence how you should write tests.

Behaviour-driven development specifies that tests of any unit of software should be specified in terms of the desired behaviour of the unit. Which is good, because, as we’ve already established testing behaviour is what lets our tests stand the test of time.

So far in this series I’ve talked about automated testing. Automated testing is an essential part of what makes sprints viable - because in order for something to be releasable it needs to work, and in order to know something works we (usually) have to test it. Thus, everything I’ve written so far is very useful in Agile environments. In this article I want to touch on the place I think manual testing has in these environments.

This post is the TLDR of my On Testing series.