On Mon, Dec 28, 2009 at 7:01 PM, Adrian Kuhn
<akuhn@iam.unibe.ch> wrote:
Alexandre Bergel <alexandre@...> writes:
> > The stored history is compiled into a method on the class side. So you get
> > the exact benefit of #expectedFailures/#expectedError. It is persistent
> > across source control and will mark your failures/errors as expected. So
> > you dont need #expectedError at all.
>
> Yep, I know this, I pair programmed the history mechanism with Simon
> But I still do not understand how do you distinguish a method that
> always fails from an expectedFailure (i.e., a method that I know will
> fail, but I do not want it to make my unit test red)?
> If we need expectedFailure, we will probably need expectedError no?
This is an aspect that I changed. An outcome is unexpected if and only if it
�does not match what is in the stored history. (For compatibility only
�#expectedFailures are added to the stored history.) So the preferred way to
�mark an outcome as unexpected is to store the history.
Try it
- remove #expectedFailures
- run all your tests (you'll get failures and errors, -> not green)
- store the history
- run all your tests again (all your defects are expected, -> green)
And just for demonstration
- introduce a new defect
- run all your tests again (one unexpected defect, -> not green)
Does this match your workflow?
The problem is if you have several others failing/error tests but that they are not expected :(
Ok...I can run only the expected ones and store them, or don't run the error/failures ones and run them later
�
--AA