---
title: "Try to avoid multiple asserts in a single unit test"
url: "https://osherove.com/blog/2005/4/14/try-to-avoid-multiple-asserts-in-a-single-unit-test.md"
canonical: "https://osherove.com/blog/2005/4/14/try-to-avoid-multiple-asserts-in-a-single-unit-test.html"
published: "2005-04-14T20:42:00"
updated: "2005-04-14T20:42:00"
tags: ["Agile Related", "Testing Guidelines"]
author: "Roy Osherove"
description: "Consider Assert failures as symptoms of a disease and Asserts as indication points or blood checks for the body of the software. The more symptoms you can find, the easier the disease will be to figure out and remove.…"
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/"
---

# Try to avoid multiple asserts in a single unit test

By Roy Osherove April 14, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines)

**Historical article** · Originally published April 14, 2005; technical details may be outdated.

**Consider Assert failures as symptoms of a disease** and Asserts as indication points or blood checks for the body of the software. The more symptoms you can find, the easier the disease will be to figure out and remove. If you have multiple asserts in one test - only the first failing one reveals itself as failed and you lose sight of other possible symptoms.

I've written about this before but I want to stress this again because this topic is more important than you might think.

Void Sum\_AnyParamBiggerThan1000IsNotSummed()

{ 
   Assert.AreEqual(3, Sum(1001,1,2); 
   Assert.AreEqual(3, Sum(1,1001,2); 
   Assert.AreEqual(3, Sum(1,2,1001);
}
 
There are several disadvantages to using multiple asserts in one test case.
The main one is this:

Sometimes you get a better  idea of what's wrong with the code if you have multiple test failures.

When you have multiple asserts in one single test, only the first one fails and the test execution stops for this test case. The rest of the lines in the test code never get checked - you're losing some more points of view (symptoms) that you might consider important in order to quickly discover where the problem stems from.

Another example - you're changing a piece of code and suddenly 6 tests that might seem unrelated break. If you're lucky you might realize that these tests all have one thing in common - they use some common object or method that does not work anymore. That is - it's easier to realize that the problem probably does not lie within the tests  - they are correct and logical,  but their failure is merely a symptom of a deeper problem that needs attention.

Now assume the same scenario with only one test failing - a test with multiple asserts.

Since you now see only one "symptom" you might "diagnose" the disease wrongly because you don't have all the facts. That means you'll probably spend more time investigating this problem and struggling with it  -- one of the things I see most often in these cases is this:

once you make one assert pass somehow, another one "reveals" itself in the same test and fails as well. You don't get the big picture and have to realize it step by step--Along the way you you might even make "corrections" to the code which might not have been needed but "fixed" it from a different view - fixed the symptom but not the problem. You might have introduced more changes to the system and even made it less stable in the process - all the while taking more precious time.

**More notes to consider:**

If I was writing this test after  the production code was already written, I might not have a problem with this in some situations (pressed for time etc..). But if this test is written before the tested code is written, it might prove less optimal for several reasons:

 **You'll  spend a longer amount of time writing code to make the test pass**.

   The longer you spend without running tests, the less confident you become.

**You're not focusing on a small problem anymore**.

You're focusing on a combined, larger problem, more generic  which should be solved ("this and this and this should all pass at once"). It's easy to get stuck on large problems. It's  easier to keep going while continually solving small problems one after the other.

**The more time you spend not running the tests, the more code you write that has not been tested**,

and which will probably depend on more code that has not been tested. You re more likely to present unforeseen bugs.

The previous paragraph should not come as a surprise because the more code you write between each unit tests, the smaller the likelihood that your test actually covers that code. That s because:

**Trying to make a test with three ASSERTs pass, is just like trying to make three separate test cases pass in a single bounce**:

You'll have to write more code that handles more cases and you ll probably end up writing it more generic that you would have if you were just trying to fix one test case at a time. You won't really know if your tests cover all the generic code you've just written as you would have known by making the tests pass one by one, in the simplest way possible.

Once you have multiple ASSERTs in a test case, **it's very easy and human to keep adding more asserts into the existing test** than it would be to add them using new tests. Even if those were totally different asserts in nature, the broken window theory works very well here, and leads to less maintainable and less readable tests.

**You're working more time without the "success" feedback of the green bar**.

Like it or not, the psychological effect here is important. It leads to a better coding experience and more confidence and happiness at work.

Hopefully all of these reasons should make you think twice before just jumping in without attention to your tests. You'd be surprised at how fast these symptoms add up to make the testing experience either easier and faster or much more repetitive and painful that it could have been.

## More in Agile Related

[All posts in Agile Related](https://osherove.com/blog/category/agile-related)

- Apr 15, 2005

    ### [\[Book of the month\] Working effectively with legacy code](https://osherove.com/blog/2005/4/15/book-of-the-month-working-effectively-with-legacy-code.html)

- Apr 15, 2005

    ### [What does an Agile work environment look like? Here's one variation](https://osherove.com/blog/2005/4/15/what-does-an-agile-work-environment-look-like-heres-one-vari.html)

- Apr 14, 2005

    ### [Setting Up VirtualMock in the Eclipse IDE](https://osherove.com/blog/2005/4/14/setting-up-virtualmock-in-the-eclipse-ide.html)

- Apr 11, 2005

    ### [Another Entlib example: Separate integration tests from unit tests (and learn to know the difference)](https://osherove.com/blog/2005/4/11/another-entlib-example-separate-integration-tests-from-unit.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/