What should you write in a test Assert message?
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