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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.