>>> The preferred way is to store your results into the stored >>> history. You can >>> store the history with the context menu in the test runner. To do >>> so, right >>> click in the colored status field and choose `store history`. The >>> stored >>> results are treated as the expected results then. >> >> Yes, but... how is this related to the expectedError? > > 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? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
