--- title: "Mock Object testing can cause trouble - here's why and possibly how to avoid it" url: "https://osherove.com/blog/2005/6/15/mock-object-testing-can-cause-trouble-heres-why-and-possibly.md" canonical: "https://osherove.com/blog/2005/6/15/mock-object-testing-can-cause-trouble-heres-why-and-possibly.html" published: "2005-06-15T12:58:00" updated: "2005-06-15T12:58:00" tags: ["Agile Related"] author: "Roy Osherove" description: "I got this question on the israel agile development list: I wonder about the usefulness and pitfalls of using mock objects, I'm currently using NMock, and I'd made a simple refactoring that resulted in a holy mess when…" 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/" --- # Mock Object testing can cause trouble - here's why and possibly how to avoid it By Roy Osherove June 15, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published June 15, 2005; technical details may be outdated. I got this question on the israel agile development list: _I wonder about the usefulness and pitfalls of using mock objects, I'm currently using NMock, and I'd made a simple refactoring that resulted in a holy mess when half my tests broke. I read several article about this, and there seems to be some controversy in the issue. (The latest one is [http://jeremydmiller.blogspot.com/2005/06/tdd-design-starter-kit-state-vs.html](http://jeremydmiller.blogspot.com/2005/06/tdd-design-starter-kit-state-vs.html "http") ).  Any thoughts / advice in the subject?_ Mocks are great for some things. The problem you were facing could have been because of two things: 1 – not enough code reuse in the tests Many times, refactoring the code can lead to big refactoring in the tests (adding a parameter to a constructor for example). To overcome this there are various simple rules one needs to take care of in the tests to avoid having a big chunk of tests go boom, and be able to fix such a thing form one single spot or two: code reuse. \-          always create the tested object through a factory method (only one place where the ctor is called \-          when performing the same action in multiple tests – refactor to use a helper method, so the call to the object is written only in one place \-          and so on… 2 – Mock objects assume inner workings of object so when the inner working of an object changes, (though the functionality may be the same), the test will fail. As a rule – tests involving mock objects (interaction testing) assume more about the inner workings of an object (white box testing) than regular tests (state based). If you'd like to alleviate this problem a bit, there are ways to make the test act like a state based test but still use mock objects to remove some of the dependencies. For example, use Stub objects or mock objects at a level further down the chain of interaction to receive data after it has "left" the main environment on which you test. An example of this might be that you'd like to test an email message, where instead of replacing the mail sender object with a mock, you replace the an object further down the chain (the mail server? The TCP stack?). When stuff is taken one level further away, the odds are not matter what refactoring you do, the outcome on the receiving end, although in some form of "raw" state, should be the same, and so acts much like state based. Only this time the state that you test is located much closer that it would have been without mock objects.. You can also check out the latest presentation slides and code from agile Israel where I demonstrate some dependency breaking techniques: [http://www.agileisrael.com/LinkClick.aspx?link=58&mid=362](http://www.agileisrael.com/LinkClick.aspx?link=58&mid=362 "http") ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Jun 16, 2005 ### [A good tester](https://osherove.com/blog/2005/6/16/a-good-tester.html) - Jun 16, 2005 ### [Mock Objects vs. "Inherit & Override"](https://osherove.com/blog/2005/6/16/mock-objects-vs-quotinherit-amp-overridequot.html) - Jun 13, 2005 ### [Test event logic easily with the EventsVerifier class](https://osherove.com/blog/2005/6/13/test-event-logic-easily-with-the-eventsverifier-class.html) - Jun 5, 2005 ### [Agile Linux? Linux Kernel gets nightly build & Test](https://osherove.com/blog/2005/6/5/agile-linux-linux-kernel-gets-nightly-build-amp-test.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/