<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m excited to see these improvements arrive in XCTest. Up till now, I’ve been using helpers like:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">expectingThrowsAnyError(“message goes here”) {</div><div class="">&nbsp; &nbsp; // do some set-up for the call</div><div class="">&nbsp; &nbsp; let result = try CallSomeThrowingMethod()</div><div class="">&nbsp; &nbsp; XCTAssertEqual(result.foo, expectedFoo)</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Concretely, this means I cannot write a test like func testProvidingNegativeCountViolatesPrecondition() { … } that actually tests this element of the API specification.</div><div class=""><br class=""></div><div class="">Thanks,<br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">--<br class="">Jeremy W. Sherman<br class=""><a href="https://jeremywsherman.com/" class="">https://jeremywsherman.com/</a></div>

</div>
<br class=""><div><blockquote type="cite" class=""><div class="">El 13 ene 2016, a las 19:52, Chris Hanson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; escribió:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks, everyone, for all of the feedback.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">1. We’re going to let test methods throw, and treat those as unexpected failures, as planned.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">3. We’re going to add the <font face="Menlo" class=""><span style="font-size: 11px;" class="">XCTAssertThrowsError</span></font> assertion, incorporating Kevin Ballard’s suggestion for how to avoid the “<font face="Menlo" style="font-size: 11px;" class="">_ = blah()</font>” in its expression.</div><div class=""><br class=""></div><div class="">4. We’re <i class="">not</i>&nbsp;going to add the ability for <font face="Menlo" class=""><span style="font-size: 11px;" class="">XCTAssertThrowsError</span></font> to check that a specific error was thrown. This could definitely be useful but would require the function to take an <font face="Menlo" class=""><span style="font-size: 11px;" class="">ErrorType</span></font> instance that also conforms to <font face="Menlo" class=""><span style="font-size: 11px;" class="">Equatable</span></font>. 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 <font face="Menlo" class=""><span style="font-size: 11px;" class="">XCTAssertThrowsError</span></font>.</div></blockquote><div class=""><br class=""></div><div class="">We’re going to start landing these changes today, so thanks again for all of your attention and feedback!</div><div class=""><br class=""></div><div class="">&nbsp; -- Chris</div><div class=""><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=vOMsL-2B-2FXGAphIObAacT5v3Vp-2BKKQQ4edFGYZbACV1OvGIvrIpGmDhvgb0iIQSNsPLm343OT8EjBsO3ZBMcJtNCvNrocfPGxwFh8wp42yyqIm2UfsDYkVi5v97OL8arWhH9GhClCso2czxq0FBgojgMbX34DUU9PHXqjWVg0strOyn4U10k1Tap18AgtPbgJdpmCXoA-2B8QMcd-2Bkf-2BXmLUkWfeGYwTg-2B7uJU9lAgKjn-2FuU7QuBOQV4YPYhMUT3fw9P" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>