--- title: "Why you should think about TOOP- Testable Object Oriented Programming" url: "https://osherove.com/blog/2007/2/25/why-you-should-think-about-toop-testable-object-oriented-pro.md" canonical: "https://osherove.com/blog/2007/2/25/why-you-should-think-about-toop-testable-object-oriented-pro.html" published: "2007-02-25T15:36:06" updated: "2007-02-25T15:36:06" tags: ["Agile", "Agile Related", "Architecture", "Art Of Unit Testing", "Unit Testing"] author: "Roy Osherove" description: "Update: Mark has a point - Using \"TOOP\" and \"TOOD\" are catchier acronyms - I've changed them accordingly. I think it's time that Object Oriented Design\\Programming got a little face lift. We live in interesting times,…" 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/" --- # Why you should think about TOOP- Testable Object Oriented Programming By Roy Osherove February 25, 2007 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related), [Architecture](https://osherove.com/blog/category/architecture), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published February 25, 2007; technical details may be outdated. _Update: Mark_ [_has a point_](http://blogs.msdn.com/ploeh/archive/2007/02/28/ToodToop.aspx) _- Using "TOOP" and "TOOD" are catchier acronyms - I've changed them accordingly._ I think it's time that Object Oriented Design\\Programming got a little face lift. We live in interesting times, where quality and the quest for testability and continuous integration are starting to sprout all over the development world. It's in these times that one needs to think about one simple fact - in many ways, **pure** object oriented design does not go well hand in hand with the notion of **[testable design](http://weblogs.asp.net/rosherove/articles/Design4Tesatbility1.aspx)**. I wrote [about a classic example of this in this post](http://weblogs.asp.net/rosherove/archive/2007/02/25/fxcop-is-heading-in-the-wrong-direction-no-testability-whatsoever.aspx) - FxCop is removing Testability features in favor of object oriented pureness. here are some examples for this dissonance in which OOP\\OOD usually says "hide" while Testable design guidelines dictate "Expose": - **OOD**:  Do not expose any private members or methods that are not needed by the developer using your API . - **Testable**: Find a way to expose or replace private instances of objects using interfaces, injection patterns, public setters and more. - **OOD**: Seal classes to inheritance by default unless you explicitly mean for others to extend them - **Testable**: Don't seal by default (unless it's a security risk) so that others can reuse your code and override what they need in their tests. - **OOD**: only make methods virtual explicitly (in java methods are virtual by default which is an interesting strategy which I very much like) when you want others to override them. - **Testable**: when possible, make virtual the default so that inheritors can override them to break any dependencies found in their tests. - **OOD**: Use singletons to make sure only one instance exists. do not allow anyone to touch that private instance. - **Testable**: Allow others to replace Singleton instances to break any dependencies in their tests. - **OOD**: make types private or internal by default unless you want to expose them specifically. - **Testable**: Think about and expose types that you know would help the testability of your API - **OOD**: Don't add unnecessary APIs - **Testable**: Add special APIs like methods, interfaces and types especially for testability purposes. These **are** necessary. What if we added the word "Testability" into the OOD paradigm? "Testable Object Oriented Design: **TOOD**" "Testable Object Oriented Programming: **TOOP**" This paradigm would take into account the testability factor of each design, and will allow for specific design issues to be solved with testability as the winner. In many ways you can't have a truly testable design without the proper (and heavy) use of some of the object oriented principles (polymorphism is as ubiquitous in testable designs as [Falafel](http://en.wikipedia.org/wiki/Falafel) in Israel - everywhere you look there's another corner offering it). Combining the values of both paradigms will lead to a better and more solid future for software quality for all of us. But where do we start? ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Mar 7, 2007 ### [JUnit 4 feels like NUnit with attribute-like syntax](https://osherove.com/blog/2007/3/7/junit-4-feels-like-nunit-with-attribute-like-syntax.html) - Mar 2, 2007 ### [Testable Designs - Round 2: Tooling, Design Smells and Bad Analogies](https://osherove.com/blog/2007/3/2/testable-designs-round-2-tooling-design-smells-and-bad-analo.html) - Feb 25, 2007 ### [FxCop is heading in the wrong direction - No testability whatsoever](https://osherove.com/blog/2007/2/25/fxcop-is-heading-in-the-wrong-direction-no-testability-whats.html) - Feb 24, 2007 ### [Introducing FxCopUnit - A framework for integrated FxCop rule testing](https://osherove.com/blog/2007/2/24/introducing-fxcopunit-a-framework-for-integrated-fxcop-rule.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/