--- title: "The Case For Typemock" url: "https://osherove.com/blog/2008/1/20/the-case-for-typemock.md" canonical: "https://osherove.com/blog/2008/1/20/the-case-for-typemock.html" published: "2008-01-20T15:59:53" updated: "2008-01-20T15:59:53" tags: ["Agile", "Art Of Unit Testing", "Unit Testing"] author: "Roy Osherove" description: "I just wrote an email to someone regarding Typemock . We were discussing why they don't think Typemock holds the values that other mocking frameworks hold when I suddenly realized what I've been wanting to say all along…" 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/" --- # The Case For Typemock By Roy Osherove January 20, 2008 In [Agile](https://osherove.com/blog/category/agile), [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 January 20, 2008; technical details may be outdated. I just wrote an email to someone regarding [Typemock](http://typemock.com/). We were discussing why they don't think Typemock holds the values that other mocking frameworks hold when I suddenly realized what I've been wanting to say all along about Typemock, and why it's a viable option for organizations _(disclosure - I recently started working at Typemock)_ _Before you read what I wrote,_ you can read posts that say "don't use Typemock" [here](http://www.mockobjects.com/2008/01/just-when-you-thought-it-was-safe-to-go.html), [here](http://codebetter.com/blogs/jeremy.miller/archive/2008/01/18/typemock-isn-t-too-powerful-and-quot-designing-for-testability-quot-is-much-more-than-merely-mocking-anyway.aspx),[here](http://jayflowers.com/WordPress/?p=77) and there are others. Most fear that Typemock will make it easy for you to write non testable code, or that your design will suffer for it. You can read my thoughts on this [here](http://weblogs.asp.net/rosherove/archive/2008/01/17/is-typemock-too-powerful-will-it-kill-design-for-testability.aspx) and [here](http://weblogs.asp.net/rosherove/archive/2008/01/18/dependency-injection-is-it-relevant-beyond-unit-testing.aspx). The following is in argument of people saying that Typemock contradicts the agile values of TDD and unit testing by supplying workarounds for common testability problems. The trick is to look at the bigger picture. sometimes you are looking at details so up close that you lose site of the whole idea behind mocking frameworks to begin with. **Making the team more agile**. **Easier to digest** **Typemock is to Rhino.Mocks as Scrum is to eXtreme Programming**\- one is much easier(less scary) to swallow to the uninitiated than the other,  but they eventually lead to the same overall result - a team that can do a better job with better feedback. It is a business oriented mocking framework. It speaks in a language that managers who don't feel "agile" can understand. It will help them write tests for existing code, it will help them write tests more easily on new code as well. It will be a bigger ROI than the other frameworks because of these benefits. That, in turn, means that Typemock is easier to adopt in non agile\\unit testing organizations, but it still plants that agile seed in there. The developer that today uses it to write tests against their legacy code, will write unit tests with it tomorrow on greenfield code. it  is their choice when to use it, but at least now they have a tool that was "insertable" into the organization which can now be used for more and more agility in the dev team. **A bridge between Agile and Non Agile** Typemock is a "bridge" between the pure, extreme, agile world and the business oriented, manager facing, legacy ridden, agile fearing world that we all love to whine about so much. Because it tries to speak to that world, and to those managers who don't want to give up their existing OO beliefs (designing for testability?), it also feels controversial to the pure agile world. it is neither here nor there. not pure Agile\\Testability but also allows agility through unit testing if you use it right. That means it's also in both worlds - it connects the business and agile world by making writing tests simpler, and the trouble of learning the techniques is easier to explain. **Typemock can help drive change where others can't** Typemock can drive change in non agile organizations sometimes more than other frameworks such as RhinoMocks or NMock, simply because it will cater to needs (such as legacy code, non testable code) that the other frameworks do not make possible. That is what makes it unique, and what makes it so different that the agile world doesn't quite know how to swallow it. **Don't be dogmatic** And if you really feel that you wouldn't recommend Typemock because it doesn't subscribe to the way you think things should be done, aren't you being a little dogmatic? agile is about embracing **what works for a particular team** and Typemock certainly does solve lots of problems for real teams. Just because they don't use concepts we're used to as often, doesn't mean they aren't becoming more and more agile every day. Update: I posted a [10 minute intro video to Typemock](http://weblogs.asp.net/rosherove/archive/2008/01/21/video-typemock-basics-lesson-1-dependency-breaking-101.aspx) here. ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Jan 25, 2008 ### [Research Finds TDD Boosts Developer Productivity](https://osherove.com/blog/2008/1/25/research-finds-tdd-boosts-developer-productivity.html) - Jan 21, 2008 ### [Video: Typemock Basics - Lesson 1 (Dependency breaking 101)](https://osherove.com/blog/2008/1/21/video-typemock-basics-lesson-1-dependency-breaking-101.html) - Jan 20, 2008 ### [TDD Anti Patterns](https://osherove.com/blog/2008/1/20/tdd-anti-patterns.html) - Jan 18, 2008 ### [Trying out Team City - Looks Promising!](https://osherove.com/blog/2008/1/18/trying-out-team-city-looks-promising.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/