--- title: "8 techniques to find problems in your unit tests within 30 seconds" url: "https://osherove.com/blog/2009/8/31/8-techniques-to-find-problems-in-your-unit-tests-within-30-s.md" canonical: "https://osherove.com/blog/2009/8/31/8-techniques-to-find-problems-in-your-unit-tests-within-30-s.html" published: "2009-08-31T06:18:49" updated: "2009-08-31T06:18:49" tags: [] author: "Roy Osherove" description: "when reviewing tests, there are “easy finds” you can have. Here’s how I might start search for the following issues: Trust issues – can I trust the test (is it repeatable, conssistent and tests the right thing? Search…" 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/" --- # 8 techniques to find problems in your unit tests within 30 seconds By Roy Osherove August 31, 2009 **Historical article** · Originally published August 31, 2009; technical details may be outdated. when reviewing tests, there are “easy finds” you can have. Here’s how I might start search for the following issues: **Trust issues – can I trust the test (is it repeatable, conssistent and tests the right thing?** - **Search the test project for use of “DateTime.”**  using DateTime in your tests means that everytime you run the test, you’re essentially running a **different** unit test. if it somehow fails due to the datetime, there might not be an easy way to recreate the failing test (if you’ve never logged the datetime being used) - **Search the Test Project for any word to do with Threads**  if you’re using threads, then your test might break due to threading issues, and not logic issues. even running it on a slow machine, or a machine with multiple CPUs changes the test execution. It’s ok for an integration test, but not for a unit test, which should **always** have the same result. - **Search for “Environment.” (ignore newline)** If you’re using anything from the current environment, then there are two possible things happening: You run a different a test every time you change your test machine, and your test may be repeating the logic that exists in the production code. Instead, try to fake the environment values (abstract them away) and have hard coded expected values in your tests. otherwise- you have an integration test. **Maintainability issues – how fragile are the tests? will the break even if the code under test changes, but isn’t broken?** - Use Resharper to search for the “.Verifiable” method, and **group by member**. there should be no more than one per test.  If there is then you are testing more than one thing – and your test is more fragile since it over-specifies internal behavior. any internal change in the code, even if the end behavior is OK, can break your test quite easily. - If using **Moq**: Search for “.VerifyAll”  - you are again over specifying the test, making it fragile and easy to break for the wrong reason. You should verify only on a single mock object. - If using **Rhino Mocks**: Search for multiple .AssertWasCalled or multiple Verify() or VerifyAll() for the same reason above. - If using **Isolator**: Search for multiple Verify() calls in one test for the same reasons - Search for creation of the objects under test inside the test – this is a big chance for refactoring – if you don’t, and the constructor for the object changes – you will have to change all these tests as well. Refactor to a factory method, or use the Setup method in the tests. Again – these are all “easy wins”. there are things which take a bit more digging up to find, which will greatly improve your tests. for more examples see: - [My book](http://artofunittesting.com/), the art of unit testing, has a bunch of test review guidelines at the last page - My [test review videos](https://osherove.com/videos/category/test-review) --- ## 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/