Test Case Best Practice: It’s better to LogPass than to LogFailure
In our test case world, we assume a test case fails, unless we log pass. We changed our way of thinking a while ago, where we used to assume a test case passes, unless we log a failure. I wish I could give an example of a bug I’ve caught because of the change, but I’ve never been able to identify one that was caught exclusively because of log pass. I’ve been asking people on my team if they have any examples of bugs and other benefits from the log pass, but most people are on vacation right now. If I get more info from them after the holidays, I’ll do a follow-up post.
Here are some benefits:
- It significantly improves the readability of your test case.
- It makes the test case much easier to write and gives the test case writing more confidence in what is being verified.
- You have a higher chance of catching failures that do not meet your specific “pass” criteria.
- If, for whatever reason, the test case doesn’t explicitly log a pass, a failure is logged automatically.
Simple example:
LogPass()
If currentLineAfterDelete = currentLine.Remove(whitespaceLocation, 1) Then
LogPass()
Else
LogFailure("Failed to delete whitespace…")
End If
Versus LogFailure()
If currentLineAfterDelete <> currentLine.Remove(whitespaceLocation, 1) Then
LogFailure("Failed to delete whitespace…")
End If