On 2014-02-25, at 17:04, btc@openinworld.com wrote:
I'd like to better understand the semantics of "expected failures" in TestRunner. It seems to me that if you want to ensure that a certain operation fails, in a test you'd wrap it as follows...
shouldFailed=false.
[ self operationThatShouldFail ] on: Error do: [ shouldFailed := true ].
self assert: shouldFailed.
I prefer:
self should: [ self operationThatShouldFail ] raise: ASpecificError
Otherwise you can just run the code itself:
self operationThatShouldFail
the test framework will take care of it and mark the test correctly as a failure.
Camillo, I don't quite follow your second case. Do you refer to using
<expectedFailure> ? Doing that might be community convention,
but "expected failures" for this makes me uncomfortable. It is not
specific about what the failure should be, so the occurrence of
non-expected failures is masked. I really like #should:raise since it
is specific. It would be nice if as many <expectedFailure>s as
possible were converted to #should:raise, with <epxectedFailure>
being used only for fubared tests being prioritised to deal with later
on, with the ultimate goal of having no <expected Failure>s in
the image.