[swift-evolution] Proposal: XCTest Support for Swift Error Handling

[Jérôme Duquennoy]

This though comes from the rules applied in my dev team : one of those rules specifies a pretty strict formatting of unit tests, with the three different parts, separated by an empty line : setup, execute (most often one single line for unit tests, highlighted by an "// Execution" comment) and validation. The validation part regroups asserts, and can mix validation on a thrown error and on the status of an object.
This requires that the thrown error is stored in a variable at execution time, to be accessible at validation time.
This strict and consistent formatting across tests is very pleasant : it makes it easy to read tests, and analyse failures. It is a time gain when tests go red :-).

But I understand that this is a local development rule, and such rules are very different between teams.
Maybe having both possibilities (the error handling bloc and the return variable) would be ideal : it would fit all situations.

Jérôme

> Le 14 janv. 2016 à 20:34, Mike Ferris <mferris at apple.com> a écrit :
> 
> Do you think that approach has a specific advantage over the current approach where the thrown error is passed into the optional block parameter?
> 
> They seem more or less equal in what they allow you to accomplish and I kind of like the scoping of the code to check the error within the block associated with the assert that catches the throw…
> 
> 
> Mike
> 
>> On Jan 14, 2016, at 11:31 AM, Jérôme Duquennoy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> 4. We’re not going to add the ability for XCTAssertThrowsError to check that a specific error was thrown. This could definitely be useful but would require the function to take an ErrorType instance that also conforms to Equatable. We need to think about that some more before making such a change. Fortunately this sort of addition will be straightforward to put in via an overload or default argument, so if we choose to do it later, it shouldn’t break any code that starts to adopt XCTAssertThrowsError.
>> 
>> Wouldn't it be possible to have XCTAssertThrowsError return the thrown error, so that the dev can do it's own test (validating an error code for exemple) ?
>> This would be fairly easy to implement (see the code I proposed on the 11th), and very flexible (it allows any dev to validate whatever he wants in its custom error type).
>> 
>> Jérôme
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/8bf467a1/attachment.html>