Camillo Bruni wrote:
On 2014-02-25, at 17:04, b...@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.

cheers -ben

Reply via email to