be consistent about reporting failures vs errors
Reported by David Chelimsky | November 28th, 2007 @ 02:44 PM
Check out this report:
The error and failure are presented differently in the verbose reporting, but are reported as just failures in the summary at the bottom.
This should be consistent. Either failures and errors should all say FAILURE and turn up red, or the summary should split them out.
Comments and changes to this ticket
-

Dan North November 29th, 2007 @ 12:39 AM
- → State changed from new to open
I have to say, this failures vs errors drives me nuts. It's either working or it isn't working, and that's all I need to know. (Ok, it can be pending, but that's a different story).
The idea of differentiating between errors and failures dates back to junit 1.0 when the world consisted of tests and assertions, and it was deemed useful for a developer to know whether a test failed because their code didn't catch an error or because an assertion failed.
I have never found any value in distinguishing between the two. That's not how behaviour works, and ironically it's not how testing works either. The application either behaves or it doesn't, both at a code level and at a feature level. We have more sophisticated tools now like mocks that can provide interaction-based assertions. What happens when one of those fails fast (correctly) at runtime? Is that an error or a failure?
And what if a mock raises an exception (because it's supposed to) and the application doesn't catch it but it should? Does that count as an error or a failure? And does anyone even use that vocabulary: "The application is erroring."
I say kill off any reference to errors and make everything bad a failure. (Or maybe replace both error and failure with "constructive feedback" :)
3 examples, 1 succeeded, 2 have talents elsewhere
-
Pat Maddox December 6th, 2007 @ 01:02 PM
I prefer it the way it is, honestly. I find it useful that errors and failures appear differently in the output. It lets me know if my code is wrong, or if my code is broken - aka I'm missing a class or a method, usually. Errors are roughly the same as "lean on the compiler" in my mind. So I guess my cycle is often pink->red->green->refactor :P
As for the summary, I don't think it should be split out. I know it seems like a mismatch, but I don't have any more insight if the summary says I've got 1 failure and 1 error instead of 2 failures. As it is, I just see there's 2 failures, and when I examine why, I find that it's because there's an error. Good enough for me.
Just my two cents, and this is minor and I doubt I'll say anything else on it
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Behaviour Driven Development for Ruby.
