--- title: "Preventing fragile tests – how can isolation frameworks help or hinder your goal?" url: "https://osherove.com/blog/2009/7/9/preventing-fragile-tests-how-can-isolation-frameworks-help-o.md" canonical: "https://osherove.com/blog/2009/7/9/preventing-fragile-tests-how-can-isolation-frameworks-help-o.html" published: "2009-07-09T08:06:58" updated: "2009-07-09T08:06:58" tags: ["Agile", "Typemock", "Unit Testing"] author: "Roy Osherove" description: "One of the things that inhibits unit tests in organizations is the idea of fragile tests. a Fragile test is a test that can easily break when the production code changes. That’s not to say that tests should never break…" 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/" --- # Preventing fragile tests – how can isolation frameworks help or hinder your goal? By Roy Osherove July 9, 2009 In [Agile](https://osherove.com/blog/category/agile), [Typemock](https://osherove.com/blog/category/typemock), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published July 9, 2009; technical details may be outdated. One of the things that inhibits unit tests in organizations is the idea of _fragile_ tests. a Fragile test is a test that can easily break when the production code changes. That’s not to say that tests should _never_ break as you change production code, but there are ways to minimize this effect so that when tests _do_ break, they break for the _right_  reason. **the right reason** is when a feature in production code isn’t working. **the wrong reasons** can be many and varied. Of the most common ones is the idea of **over specification** in tests. The more your test expects of your code’s internal implementation, the more “specified” it is, the more “expectations” it has on the internals of the code. since internal code is more proone to change, so will the test break more often. so the situation can occur that the production code changed, but still gets the job done, but since it’s doing it differently internally, the test breaks even though the end result is still OK. One of the main ideas in the [new Isolator API](http://blog.typemock.com/search/label/AAA) was to reduce the fragility of tests by default. there are several features in Typemock Isolator that remove lots of fragility from tests by default, compared to other tools. **What do you think they are?** ([look here for hints](http://blog.typemock.com/search/label/AAA)) I found at least 8 separate things. what do other tools like Rhino Mocks, or Moq do to help or hinder the fragility of your tests? \*[here is a search that will help](http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=Nsa&q=%2Bfragile+test+moq+rhino+mocks+nmock&aq=f&oq=&aqi=)\* I’ll post my own answers tomorrow. but I’d like to see if people actually “get” how important the API of an isolation framework is to this cause. ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Jul 22, 2009 ### [Lean and Kanban Videos](https://osherove.com/blog/2009/7/22/lean-and-kanban-videos.html) - Jul 9, 2009 ### [Minimizing unit Test Fragility – 8 features in Typemock Isolator to help](https://osherove.com/blog/2009/7/9/minimizing-unit-test-fragility-8-features-in-typemock-isolat.html) - Jul 7, 2009 ### [Art of Unit Testing on Hanselminutes](https://osherove.com/blog/2009/7/7/art-of-unit-testing-on-hanselminutes.html) - Jul 7, 2009 ### [TDD Master class in Kent, UK](https://osherove.com/blog/2009/7/7/tdd-master-class-in-kent-uk.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/