Hi, On Jul 10, 2013, at 3:01 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-10, at 14:47, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 10, 2013, at 1:47 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-10, at 13:32, Tudor Girba <tudor@tudorgirba.com> wrote:
Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error).
In which sense?
In the sense that they express two distinct classes of problems.
As a programmer I have to tackle them both the same way: start debugging.
Yes, but not all debugging is created equal :)
I really do not see the difference. In both cases the code does not behave as expected. One might even say that there is a global contract that the code does not raise exceptions.
Yes, but then what is the point of explicit assertions? :)
Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures
Actually, it is the other way around :). Errors are much faster to fix than failures. Errors are often caused by bad initializations and you can see it rather fast when you see the exceptions. On the other hand, failures are often more sensitive to the deep semantics of your code and that is why they require more time to get fixed.
That is fun, because everybody first takes the yellow ones because they come on top...
Really? I think people pick and choose (or at least try to) before fixing a test. So, any hints that help people with this choice is a good thing. This is why the premise of Phexample could bring so much value because besides the fluent interface, it builds a tree of tests.
So in the end the results should just be grouped by type of error I think.
That is actually a rather cool idea. I would be happy to join playing with such an idea. Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."