Blog

The Designing versus Testing Mindset

March 12, 2020

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.

If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at our trainings and workshops or check out the books section. Feel free to reach out at infonull@nullprincipal-itnull.be.

Profile picture of Jan Van Ryswyck

Jan Van Ryswyck

Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.

Comments

Latest articles

Tags

Disclaimer

The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.

About

Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.

Latest articles

Contact information

(+32) 496 38 00 82

infonull@nullprincipal-itnull.be

principal-it.eu
principal-it.be
janvanryswyck.com