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? --AA