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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project