Why it is better to log failure by default in a test case rather than to log pass by default – Part 2

As promised, I said I would ask some of the people from my team after they returned from vacation about the history of LogPass. I met with one of our SDET Leads to find out more. Here’s what I learned.

Logging failure by default is a Test-Driven Development best practice.

Logging failure by default is a good best practice because it catches mistakes made by the test case writer. For example, here’s a scenario that would only be caught by logging failure by default unless the test case writer explicitly calls log pass.

‘ begin scenario 1

If CurrentFileName = “foo” Then

‘ do specific verifications for foo

‘ log pass if correct

‘ otherwise, log failure

ElseIf CurrentFileName = “bar” Then

‘ do specific verifications for bar

‘ log pass if correct

‘ otherwise, log failure

End If

‘ begin scenario 2

Suppose the current file name was “TextFile1”. If we didn’t log failure by default, this scenario would have simply succeeded, because it never had the chance to do any verifications. Logging failure by default means that you check assumptions made by the test case writing. As in the above example, log failure by default catches the assumption that the file name will always be either foo or bar.

And another way to look at whether to log failure or to log pass:

It is an optimization for quality when log failure is default.

It is an optimization for time when log pass is default.