The Designing versus Testing Mindset

Previously, we touched on two different categories of automated tests, namely solitary and sociable tests. Also we discussed how and why the test pyramid is a useful model to have a healthy mix of both kinds of tests. The bottom line of the previous blog post is that only having high-level sociable tests without any solitary tests, basically an “ice cream cone” testing strategy, can be quite detrimental.

Why? Because solitary and sociable tests each serve different purposes. They serve different purposes because they stem from a different mindset.

Solitary tests originate from a “design” mindset. Solitary tests apply a certain pressure on the design of the system. They clearly indicate design flaws when they pop up. In order to accomplish this, we isolate small parts of the system and drive their design using Test-Driven Development. The process of TDD is about learning and designing. The solitary tests that come out of this process are merely a useful side-effect.

Sociable tests are only about verifying an expected outcome, which is just fine and very much needed as well. Sociable tests originate from a “testing” mindset. They don’t drive or put any pressure on the design of the system. The reason for this is that they are inherently farther removed from the detailed implementation. Sociable tests are usually more verbose and therefore take longer to write. Because their inherit nature of taking more time to write and to run, it’s not really feasible to let them participate in a fast feedback process.

There is a process named Acceptance Test-Driven Development (ATDD), which is related to TDD, but is more focused on being a collaborative process between users, testers and developers. This can be a useful process for driving out sociable tests.

The focus of solitary and sociable tests are completely different. And again, this is all fine because designing and testing software are two entirely different things. We need a lot of “designing” as well as “verification” activities in order to build useful software systems. Make sure to have both instead of choosing only one over the other.