---
title: "What should you write in a test Assert message?"
url: "https://osherove.com/blog/2005/4/10/what-should-you-write-in-a-test-assert-message.md"
canonical: "https://osherove.com/blog/2005/4/10/what-should-you-write-in-a-test-assert-message.html"
published: "2005-04-10T22:50:00"
updated: "2005-04-10T22:50:00"
tags: ["Agile Related", "Testing Guidelines"]
author: "Roy Osherove"
description: "The Assert message in a test is one of the most important parts. It's there to tell us what went wrong with our code. what we expected to happen but didn't, and what should have happened instead. A good assert message…"
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/"
---

# What should you write in a test Assert message?

By Roy Osherove April 10, 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 10, 2005; technical details may be outdated.

The Assert message in a test is one of the most important parts. It's there to tell us what went wrong with our code. what we expected to happen but didn't, and what should have happened instead. A good assert message helps us track bugs and understand unit tests more easily.

Sadly, most developers new to automated unit tests usually leave the assert messages to last (which means they never get written correctly).

**DO**

- Express what **should** have happened or what **did not** happen
    - "Foo should have thrown an exception"
    - "Foo did not throw any exception" (not as good as the previous one)
    - "Foo should have returned a new ID"
    - "Foo should not allow negative numbers as parameters"
    - "Foo should open the connection before returning it"
    - "Foo did not open the connection before returning it"
    - "Person class did not have a valid GUID by default"

**Don't**

- Provide empty or meaningless messages
- Provide messages that repeat the name of the test case
- Provide messages that simply state the test inputs

## More in Agile Related

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

- Apr 11, 2005

    ### [Enterprise library -- Test usability and "runnability"](https://osherove.com/blog/2005/4/11/enterprise-library-test-usability-and-quotrunnabilityquot.html)

- Apr 10, 2005

    ### [Making your tests withstand design and interface changes - remove code duplication](https://osherove.com/blog/2005/4/10/making-your-tests-withstand-design-and-interface-changes-rem.html)

- Apr 10, 2005

    ### [Agile Israel news and updates](https://osherove.com/blog/2005/4/10/agile-israel-news-and-updates.html)

- Apr 8, 2005

    ### [CFNUnitBridge: Test Driven Development for the .NET compact framework(almost there)](https://osherove.com/blog/2005/4/8/cfnunitbridge-test-driven-development-for-the-net-compact-fr.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/