--- title: "[Article] Achieving And Recognizing Testable Software Designs – Part I" url: "https://osherove.com/blog/2006/3/19/article-achieving-and-recognizing-testable-software-designs.md" canonical: "https://osherove.com/blog/2006/3/19/article-achieving-and-recognizing-testable-software-designs.html" published: "2006-03-19T09:35:00" updated: "2006-03-19T09:35:00" tags: ["Agile Related", "Team Agile News"] author: "Roy Osherove" description: "Recently, I’ve had the pleasure of speaking at a Microsoft Dev/IT Pro Days conference in Belgium . I was approached by the organizers asking if I would want to do a session on “Designing for testability”, as part of…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # \[Article\] Achieving And Recognizing Testable Software Designs – Part I By Roy Osherove March 19, 2006 In [Agile Related](https://osherove.com/blog/category/agile-related), [Team Agile News](https://osherove.com/blog/category/team-agile-news) **Historical article** · Originally published March 19, 2006; technical details may be outdated. Recently, I’ve had the pleasure of speaking at a Microsoft Dev/IT Pro Days conference in Belgium.  I was approached by the organizers asking if I would want to do a session on “Designing for testability”, as part of three talks I was to give there. The topic was not something I had spoken about before, but definitely something I had thought about, considered and wrestled with many times on many projects and occasions. I set out to first determine what the definition of a “Testable System” might be, in my eyes. I came to the realization that a testable system is not measured in a vacuum, but its testability has to be “mirrored” through external testing related factors. For example, how easy would it be to write **quality unit tests** against such a system? And for that question to be answered, one has to ask **what “quality unit tests” really means** in this context. In this article we’ll try to define what a testable system design really means, and explore some basic design rules to make sure we can keep that testability in the system from the beginning. Here’s my current definition of a testable system: _“For each **logical part** of the system, a unit test can be written **relatively** **easily and quickly** that satisfies **all** the following PC-COF rules at the same time:_ **_P_**_artial runs are possible_ **_C_**_onsistent results on every test run_ **_C_**_onfiguration is unneeded before run_ **_O_**_rder of tests does not matter_ **_F_**_ast run time”_ [Read the rest of the article here](http://weblogs.asp.net/rosherove/articles/Design4Tesatbility1.aspx) and read about each of the five rules outlined here. ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Mar 27, 2006 ### [Special Agile Israel Meeting Today!](https://osherove.com/blog/2006/3/27/special-agile-israel-meeting-today.html) - Mar 23, 2006 ### [Some goodness from CodeBetter.Com](https://osherove.com/blog/2006/3/23/some-goodness-from-codebettercom.html) - Mar 13, 2006 ### [Code from DevDays Belgium available: Design for Testability & Smart Client Offline Caching and Synchronization](https://osherove.com/blog/2006/3/13/code-from-devdays-belgium-available-design-for-testability-a.html) - Mar 10, 2006 ### [March at Agile Israel - Great presentations & The group's first birthday](https://osherove.com/blog/2006/3/10/march-at-agile-israel-great-presentations-amp-the-groups-fir.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/