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

[Jeremy W. Sherman]

I’m excited to see these improvements arrive in XCTest. Up till now, I’ve been using helpers like:

expectingThrowsAnyError(“message goes here”) {
    // do some set-up for the call
    let result = try CallSomeThrowingMethod()
    XCTAssertEqual(result.foo, expectedFoo)
}

Do you see any way to address the testing gap left by not being able to catch failing preconditions? Preconditions are significant elements of the developer-facing API, and it is frustrating to be unable to drive these requirements out - and document them - using tests.

Concretely, this means I cannot write a test like func testProvidingNegativeCountViolatesPrecondition() { … } that actually tests this element of the API specification.

Thanks,
--
Jeremy W. Sherman
https://jeremywsherman.com/ <https://jeremywsherman.com/>
> El 13 ene 2016, a las 19:52, Chris Hanson via swift-evolution <swift-evolution at swift.org> escribió:
> 
> Thanks, everyone, for all of the feedback.
> 
> I sent this proposal out as more of a “heads up” that we were planning to make these changes and get feedback in advance of that, so we won’t be taking this through the full proposal process. That said, here’s what we’re going to be doing:
> 
> 1. We’re going to let test methods throw, and treat those as unexpected failures, as planned.
> 
> 2. We’re going to let test assertion expressions throw, and treat those as unexpected failures, as planned. We recognize that this will result in slightly different style in tests versus in regular code, but the convenience and reduction in boilerplate makes this worthwhile.
> 
> 3. We’re going to add the XCTAssertThrowsError assertion, incorporating Kevin Ballard’s suggestion for how to avoid the “_ = blah()” in its expression.
> 
> 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.
> 
> We’re going to start landing these changes today, so thanks again for all of your attention and feedback!
> 
>   -- Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> 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-corelibs-dev/attachments/20160114/d093f22c/attachment.html>