Here’s a tip: Write your automated tests with the failure in mind. Especially, consider a future maintainer who may need a useful error message.
This can help when the test fails in the future (and it probably will). A descriptive message helps understand the technical issue you’re looking at and will ideally guide you to finding a solution.
Let’s look at some examples that leave something to be desired. These messages may be true, but don’t help to understand the underlying problem:
Expected true, but got false
The result message is malformed
Yes, I have seen these or very similar messages, that are rather useless.
Imagine how much more helpful, the following messages are:
Expected condition XY to be true in context AB of object O
The message ‘<output the actual message>’, is malformed and cannot be processed further
Got <actual result> instead of <expected_result> when processing XY
These improved messages can guide you, help you remember the context and figure out the underlying issue when the test fails.
I find that this improvement shortens the time spent with failure analysis. It makes my days more productive because I get a message that tells me about the context where thing went wrong.
Do you have similar ideas about how to improve (automated) tests?
I’d love to hear about them.