<div dir="ltr">RSpec, Kiwi and similar have hierarchical tests which are good because they reduce duplication and take into account the dependencies of tests - tests on the performance of objects being conditional on the verified successful creation of those objects, or on duplicated circumstances - but they also nest tests into a &#39;pyramid of doom&#39; as we had prior to &quot;if let&quot; allowing multiple bindings.<div><br></div><div>It&#39;d be nice if we could refactor huge nested structures like that into flatter subtests. Ideally I&#39;d like there to be a way to reduce repetition of duplicated code in tests (e.g. for a series of identical tests determining if a given data structure is valid, a way to call those tests with one command). It&#39;s possible to call XCTest functions in helper functions now, but hard to match any failure messages with the test which called the helper function. Perhaps such sub-test methods could throw a series of test failure messages so this can be determined more easily.</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 4:05 PM, James Campbell <span dir="ltr">&lt;<a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I wouldn&#39;t mind if we could have something closer to this. <a href="http://rspec.info/" target="_blank">http://rspec.info/</a></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 3:01 PM, Ross O&#39;Brien <span dir="ltr">&lt;<a href="mailto:narrativium+swift@gmail.com" target="_blank">narrativium+swift@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;ve been wondering for a while, while writing unit tests, why we still start with &quot;func test[behaviourOfThing]() {&quot; and not &quot;test behaviourOfThing {&quot;. It&#39;s not just about less typing: parsing a function for the &#39;test&#39; prefix is an Objective C holdover, and doesn&#39;t feel Swift to me, and it has tests behaving like functions when - as illustrated in this proposal - they should have different behaviours. It should be clearer when reading code whether a function is a test or a helper function to make tests easier to write.<div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 12:34 PM, James Campbell via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I would love it if we could do a full review of XCtest in general. As there are other things it could help with I.r mocking or allowing us to express tests in a BDD way <br><br>Sent from my iPhone</div><div><div><div><br>On 10 Jan 2016, at 10:29, Drew Crawford via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div>I have on the order of ~700 tests in XCTest in Swift-language projects.  I&#39;m considering migrating away from XCTest, although not over this issue.</div><div><br></div><div>This proposal IMO addresses an important problem, but I am not convinced it actually solves it.  #2 &amp; #3 are basically sound API designs.  It is a mystery to me why #3 &quot;generated some debate&quot; as this is a feature I already implement manually, but I can&#39;t address unknown concerns.  I can tell you I implement this, and nothing terrible has happened to me so far.</div><div><br></div><div>#1 I would not use.  The rest of this comment explains why.</div><div><br></div><div>Currently I write tests about like this:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>try! hopefullyNothingBad()</div></blockquote><div><br></div>Now this is &quot;bad&quot; because it &quot;crashes&quot; but that&#39;s (big sigh) actually &quot;good&quot; because the debugger stops and/or I get a crash report that identifies at least &quot;some&quot; line where something bad definitely happened.<div><br></div><div>Now that is not everything I <i>want</i> to know–I <i>want</i> someone to tell me a story of how this error was created deep down in the bowels of my application, how it spent its kindergarten years in the models layer before being passed into a controller where it was rethrown onto a different dispatch queue and finally ended up in my unit test–but we can&#39;t have everything.  So I settle for collecting a line number from the test case and then going hunting by hand.</div><div><br></div><div>When the test function throws we no longer even find out a line number in the test case anymore, because the error is passed into XCTest and the information is lost.  We have just the name of the test case (I assume; the proposal is silent on this issue, but that&#39;s the only way I can think of to implement it), and some of my tests are pretty long.  So, that makes it even harder to track down.</div><div><br></div><div>This sounds like a small thing but my test coverage is so thorough on mature projects that mostly what I turn up are heisenbugs that reproduce with 2% probability.  So getting the report from the CI that has the most possible detail is critical, because if the report is not thorough enough for you to guess the bug, too bad, because that&#39;s all the information you get and the bug is not reproducible.</div><div><br></div><div>For that reason, I won&#39;t use #1.  I hesitate about whether to call it bad idea altogether, or whether it&#39;s just not to my taste.  My sense is it&#39;s probably somewhere in the middle of those two poles.</div><div><br></div><div>I would use #2 and #3, assuming that I don&#39;t first migrate out to a non-XCTest framework.</div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Jan 9, 2016, at 8:58 PM, Chris Hanson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">We’d like feedback on a proposed design for adding support for Swift error handling to XCTest, attached below. I’ll mostly let the proposal speak for itself, but there are three components to it: Allowing test methods to throw errors, allowing the expressions evaluated by assertions to throw errors, and adding an assertion for checking error handling.<div><br></div><div>We’d love to hear your feedback. We’re particularly interested in some feedback on the idea of allowing the expressions evaluated by assertions to throw errors; it’s generated some debate because it results in writing test code slightly differently than other code that makes use of Swift error handling, so any thoughts on it would be particularly appreciated.<br><div><span style="text-align:right"><br></span></div><div><div><div><div>  -- Chris Hanson (<a href="mailto:chanson@apple.com" target="_blank">chanson@apple.com</a>)</div><div><div><div><div><br></div><div><br></div><div><h1 style="margin-right:0px;margin-bottom:10px;margin-left:0px;padding:0px;font-size:28px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255);margin-top:0px!important">XCTest Support for Swift Error Handling</h1><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><li style="margin:0px">Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank">SE-NNNN</a></li><li style="margin:0px">Author(s): <a href="https://github.com/eschaton" style="color:rgb(65,131,196);margin-top:0px" target="_blank">Chris Hanson</a></li><li style="margin:0px">Status: <strong style="margin-top:0px">Review</strong></li><li style="margin:0px">Review manager: TBD</li></ul><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Introduction</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Swift 2 introduced a new error handling mechanism that, for completeness, needs to be accommodated by our testing frameworks. Right now, to write tests that involve methods that may throw an error, a developer needs to incorporate significant boilerplate into their test. We should move this into the framework in several ways, so tests of code that interacts with Swift error handling is concise and intention-revealing.</p><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Motivation</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Currently, if a developer wants to use a call that may throw an error in a test, they need to use Swift&#39;s <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">do..catch</code> construct in their test because tests are not themselves allowed to throw errors.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">As an example, a vending machine object that has had insufficient funds deposited may throw an error if asked to vend an item. A test for that situation could reasonably use the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">do..catch</code>construct to check that this occurs as expected. However, that means all other tests <em>also</em> need to use either a <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">do..catch</code> or <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">try!</code> construct — and the failure of a <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">try!</code> is catastrophic, so <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">do..catch</code> would be preferred simply for better reporting within tests.</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5"><span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">testVendingOneItem</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(153,153,153)">{</span>
    <span style="color:rgb(0,119,170)">do</span> <span style="color:rgb(153,153,153)">{</span>
        vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">deposit</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">5</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(0,119,170)">let</span> item <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(221,74,104)">XCTAssertEqual</span><span style="color:rgb(153,153,153)">(</span>item<span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;Candy Bar&quot;</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(153,153,153)">}</span> <span style="color:rgb(0,119,170)">catch</span> <span style="color:rgb(153,153,153)">{</span>
        <span style="color:rgb(221,74,104)">XCTFail</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(102,153,0)">&quot;Unexpected failure: <span><span style="color:rgb(238,153,0)">\(</span>error<span style="color:rgb(238,153,0)">)</span></span>&quot;</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(153,153,153)">}</span>
<span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">If the implementation of <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">VendingMachine.vend(row:column:)</code> changes during development such that it throws an error in this situation, the test will fail as it should.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">One other downside of the above is that a failure caught this way will be reported as an <em>expected failure</em>, which would normally be a failure for which XCTest is explicitly testing via an assertion. This failure should ideally be treated as an <em>unexpected failure</em>, as it&#39;s not one that&#39;s anticipated in the execution of the test.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">In addition, tests do not currently support throwing an error from within an assertion, requiring any code that throws an error to be invoked outside the assertion itself using the same techniques described above.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Finally, since Swift error handling is a general mechanism that developers should be implementing in their own applications and frameworks, we need to make it straightforward to write tests that ensure code that implements error handling does so correctly.</p><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Proposed solution</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">I propose several related solutions to this issue:</p><ol style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)"><li style="margin:0px">Allow test methods to throw errors.</li><li style="margin:0px">Allow test assertion expressions to throw errors.</li><li style="margin:0px">Add an assertion for checking errors.</li></ol><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">These solutions combine to make writing tests that involve thrown errors much more succinct.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Allowing Test Methods to Throw Errors</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">First, we can allow test methods to throw errors if desired, thus allowing the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">do..catch</code> construct to be omitted when the test isn&#39;t directly checking error handling. This makes the code a developer writes when they&#39;re not explicitly trying to test error handling much cleaner.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Moving the handling of errors thrown by tests into XCTest itself also ensures they can be treated as unexpected failures, since the mechanism to do so is currently private to the framework.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">With this, the test from the previous section can become:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5"><span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">testVendingOneItem</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(0,119,170)">throws</span> <span style="color:rgb(153,153,153)">{</span>
    vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">deposit</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">5</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(0,119,170)">let</span> item <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(221,74,104)">XCTAssertEqual</span><span style="color:rgb(153,153,153)">(</span>item<span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;Candy Bar&quot;</span><span style="color:rgb(153,153,153)">)</span>
<span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">This shows much more directly that the test is intended to check a specific non-error case, and that the developer is relying on the framework to handle unexpected errors.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Allowing Test Assertions to Throw Errors</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We can also allow the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">@autoclosure</code> expression that is passed into an assertion to throw an error, and treat that error as an unexpected failure (since the code is being invoked in an assertion that isn&#39;t directly related to error handling). For example:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5"><span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">testVendingMultipleItemsWithSufficientFunds</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(153,153,153)">{</span>
    vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">deposit</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">10</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(221,74,104)">XCTAssertEqual</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span><span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;Candy Bar&quot;</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(221,74,104)">XCTAssertEqual</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">2</span><span style="color:rgb(153,153,153)">)</span><span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;Chips&quot;</span><span style="color:rgb(153,153,153)">)</span>
<span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">This can eliminate otherwise-dangerous uses of <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">try!</code> and streamline code that needs to make multiple assertions in a row.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Adding a &quot;Throws Error&quot; Assertion</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">In order to test code that throws an error, it would be useful to have an assertion that expects an error to be thrown in a particular case. Right now a developer writing code to test that an error is thrown has to test that error themselves:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5">    <span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">testVendingFailsWithInsufficientFunds</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(153,153,153)">{</span>
        vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">deposit</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(0,119,170)">var</span> vendingFailed <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(153,0,85)">false</span>
        <span style="color:rgb(0,119,170)">do</span> <span style="color:rgb(153,153,153)">{</span>
            <span style="color:rgb(153,0,85)">_</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(153,153,153)">}</span> <span style="color:rgb(0,119,170)">catch</span> <span style="color:rgb(153,153,153)">{</span>
            vendingFailed <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(153,0,85)">true</span>
        <span style="color:rgb(153,153,153)">}</span>
        <span style="color:rgb(221,74,104)">XCTAssert</span><span style="color:rgb(153,153,153)">(</span>vendingFailed<span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">If we add an assertion that specifically checks whether an error was thrown, this code will be significantly streamlined:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5">    <span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">testVendingFailsWithInsufficientFunds</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(153,153,153)">{</span>
        vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">deposit</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(221,74,104)">XCTAssertThrowsError</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">_</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Of course, some code may want to just detect that an error was thrown, but other code may need to check that the details of the thrown error are correct. We can take advantage of Swift&#39;s trailing closure syntax to enable this, by passing the thrown error (if any) to a closure that can itself contain assertions:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5">    <span style="color:rgb(221,74,104)">XCTAssertThrowsError</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,0,85)">_</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">try</span> vendingMachine<span style="color:rgb(153,153,153)">.</span><span style="color:rgb(221,74,104)">vend</span><span style="color:rgb(153,153,153)">(</span>row<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">,</span> column<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,0,85)">1</span><span style="color:rgb(153,153,153)">)</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(153,153,153)">{</span> error <span style="color:rgb(0,119,170)">in</span>
        <span style="color:rgb(0,119,170)">guard</span> <span style="color:rgb(0,119,170)">let</span> vendingError <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> error <span style="color:rgb(0,119,170)">as</span><span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">?</span> <span style="color:rgb(102,153,0)">VendingMachineError</span> <span style="color:rgb(0,119,170)">else</span> <span style="color:rgb(153,153,153)">{</span>
            <span style="color:rgb(221,74,104)">XCTFail</span><span style="color:rgb(153,153,153)">(</span><span style="color:rgb(102,153,0)">&quot;Unexpected type of error thrown: <span><span style="color:rgb(238,153,0)">\(</span>error<span style="color:rgb(238,153,0)">)</span></span>&quot;</span><span style="color:rgb(153,153,153)">)</span>
            <span style="color:rgb(0,119,170)">return</span>
        <span style="color:rgb(153,153,153)">}</span>
        
        <span style="color:rgb(221,74,104)">XCTAssertEquals</span><span style="color:rgb(153,153,153)">(</span>vendingError<span style="color:rgb(153,153,153)">.</span>item<span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;Candy Bar&quot;</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(221,74,104)">XCTAssertEquals</span><span style="color:rgb(153,153,153)">(</span>vendingError<span style="color:rgb(153,153,153)">.</span>price<span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(153,0,85)">5</span><span style="color:rgb(153,153,153)">)</span>
        <span style="color:rgb(221,74,104)">XCTAssertEquals</span><span style="color:rgb(153,153,153)">(</span>vendingError<span style="color:rgb(153,153,153)">.</span>message<span style="color:rgb(153,153,153)">,</span> <span style="color:rgb(102,153,0)">&quot;A Candy Bar costs 5 coins&quot;</span><span style="color:rgb(153,153,153)">)</span>
    <span style="color:rgb(153,153,153)">}</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">This lets a developer very concisely describe an error condition for their code, in whatever level of detail they desire.</p><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Detailed design</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">The design of each of the above components is slightly different, based on the functionality provided.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Tests That Throw</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">In order to enable test methods to throw an error, we will need to update XCTest to support test methods with a <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">() throws -&gt; Void</code> signature in addition to test methods with a <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">() -&gt; Void</code>signature as it already supports.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We will need to ensure tests that do throw an error have that error caught, and that it registers an unexpected failure.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Assertions That Throw</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">In order to allow assertions to throw an exception, we will need to enhance our existing assertions&#39; <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">@autoclosure</code> expression parameters to add <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">throws</code> to their signature.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Because Swift defines a closure that can throw an error to be a proper supertype of a closure that does not, this <em>will not</em> result in a combinatorial explosion of assertion overrides, and will let developers naturally write code that may throw an error within an assertion.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We will treat any error thrown from within an assertion expression as an <em>unexpected</em> failure because while all assertions represent a test for some form of failure, they&#39;re not specifically checking for a thrown error.</p><h4 style="margin:20px 0px 10px;padding:0px;font-size:16px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">The &quot;Throws Error&quot; Assertion</h4><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">To write tests for code that throws error, we will add a new assertion function to XCTest with the following prototype:</p><pre style="margin-top:0.5em;margin-bottom:0.5em;background-color:rgb(245,242,240);border:1px solid rgb(204,204,204);font-size:13px;line-height:1.5;overflow:auto;padding:1em;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-break:normal;word-wrap:normal"><code style="margin:0px;padding:0px;border:none;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,Monaco,&#39;Andale Mono&#39;,&#39;Ubuntu Mono&#39;,monospace;direction:ltr;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5"><span style="color:rgb(0,119,170)">public</span> <span style="color:rgb(0,119,170)">func</span> <span style="color:rgb(221,74,104)">XCTAssertThrowsError</span><span style="color:rgb(153,153,153)">(</span>
    @autoclosure expression<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,153,153)">(</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(0,119,170)">throws</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">-</span><span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">&gt;</span> <span style="color:rgb(102,153,0)">Void</span><span style="color:rgb(153,153,153)">,</span>
                  <span style="color:rgb(153,0,85)">_</span> message<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(102,153,0)">String</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(102,153,0)">&quot;&quot;</span><span style="color:rgb(153,153,153)">,</span>
                       file<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(102,153,0)">StaticString</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">__FILE__</span><span style="color:rgb(153,153,153)">,</span>
                       line<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(102,153,0)">UInt</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(0,119,170)">__LINE__</span><span style="color:rgb(153,153,153)">,</span>
             <span style="color:rgb(153,0,85)">_</span> errorHandler<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(153,153,153)">(</span>error<span style="color:rgb(153,153,153)">:</span> <span style="color:rgb(102,153,0)">ErrorType</span><span style="color:rgb(153,153,153)">)</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">-</span><span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">&gt;</span> <span style="color:rgb(102,153,0)">Void</span> <span style="color:rgb(166,127,89);background-color:rgba(255,255,255,0.498039);background-position:initial initial;background-repeat:initial initial">=</span> <span style="color:rgb(153,153,153)">{</span> <span style="color:rgb(153,0,85)">_</span> <span style="color:rgb(0,119,170)">in</span> <span style="color:rgb(153,153,153)">}</span><span style="color:rgb(153,153,153)">)</span></code></pre><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Rather than treat an error thrown from its expression as a failure, this will treat <em>the lack of</em> an error thrown from its expression as an expected failure.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Furthermore, so long as an error is thrown, the error will be passed to the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">errorHandler</code> block passed as a trailing closure, where the developer may make further assertions against it.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">In both cases, the new assertion function is generic on an <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">ErrorType</code> in order to ensure that little to no casting will be required in the trailing closure.</p><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Impact on existing code</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">There should be little impact on existing test code because we are only adding features and API, not changing existing features or API.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">All existing tests should continue to work as implemented, and can easily adopt the new conventions we&#39;re making available to become more concise and intention-revealing with respect to their error handling as shown above.</p><h2 style="margin:20px 0px 10px;padding:0px;font-size:24px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(204,204,204);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">Alternatives considered</h2><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We considered asking developers continue using XCTest as-is, and encouraging them to use Swift&#39;s native error handling to both suppress and check the validity of errors. We also considered adding additional ways of registering failures when doing this, so that developers could register unexpected failures themselves.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">While this would result in developers using the language the same way in their tests as in their functional code, this would also result in much more verbose tests. We rejected this approach because such verbosity can be a significant obstacle to testing.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">Making it quick and clean to write tests for error handling could also encourage developers to implement error handling in their code as they need it, rather than to try to work around the feature because of any perceived difficulty in testing.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We considered adding the ability to check that a specific error was thrown in <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">XCTAssertThrowsError</code>, but this would require the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">ErrorType</code> passed to also conform to <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">Equatable</code>, which is also unnecessary given that this can easily be checked in a trailing closure if desired. (In some cases a developer may just want to ensure <em>an error</em> is thrown rather than <em>a specific error</em> is thrown.)</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We explicitly chose <em>not</em> to offer a comprehensive suite of <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">DoesNotThrowError</code> assertions for XCTest in Swift, though we do offer such <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">DoesNotThrow</code> assertions for XCTest in Objective-C. We feel these are of limited utility given that our plan is for all assertions (except <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">XCTAssertThrowsError</code>) to treat any thrown error as a failure.</p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">We explicitly chose not to offer any additional support for Objective-C exceptions beyond what we already provide: In the Xcode implementation of XCTest, an Objective-C exception that occurs within one of our existing assertions or tests will result in a test failure; doing more than this is not practical given that it&#39;s possible to neither catch and handle nor generate an Objective-C exception in Swift.</p></div></div></div></div></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OtwgWwWn2mvmck2XIGZZg64wEmoo4f4ILYe4SqMqwHqfcfuLmH4-2Fdr1c3eLih6cI2aQ28DwPs-2BjzkC1PfxXoLj3XuDomqTNJ5B5Ux32VjiUApmOBMJ-2FhsmzZGtPlvgjtFoARNMxM8mu-2FdL8D7U1y0gCZI1hfdCmk2bFbcZB76vyPUXc91NuhiCxh2BTfMUN2eTIjEHHtgRRHIwB3lkbbBQ8HJarstwEBVTycjoVHipk-3D" alt="" width="1" height="1" border="0" style="min-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">
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=xV0JY-2FdZMnUMvSFtZnLiBPRTDDOSQf3-2FpH33HYOlBxFMEEJYY72kl0fyew-2BVxOAF-2By78SOuJn-2B6LumVFaE3apVN3KfpkYK10RFwYralJEvg4RdbeWsQrWCd45K2sJhgTaDQwvyEkzHF4AJ5dim2yGVJCNtDo0rjKHGxcq2bxfhdp-2FDeB1EiYT6rjLiQYeBs7pc9VN992yZBONMnaFdYMsbOLwI6qP895U3F7beLHVRY-3D" alt="" width="1" height="1" border="0" style="min-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">

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=-2F-2BoYEebT9nJ6Tn1eM4dmwhL8-2BwH5ixcf4jim0iIuN5yRsw5yrmv6ML6YuqDs1hGUlfC8YYrXHCxt4FvwkW31O59dJngtpzW4dXbgATzVeOKdlmF5b-2BY8hyKL7kvZizw41ctyaiiwpvfpzED2N-2FgmLqN-2FRYO1XI0avWm0y68dRfbYrNCHiuM0X1mRvbSwFNj4-2FtLx3wQ2WFxh-2BkfGG2OC1WlmuErMoIHLQQEvvfYpEJs-3D" alt="" width="1" height="1" border="0" style="min-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">
</div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><span style="font-size:16px;line-height:19.2px"></span><span style="font-size:12.8px"> Wizard</span><br></div><div><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a></div><div><a href="tel:%2B44%207523%20279%20698" value="+447523279698" target="_blank">+44 7523 279 698</a></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div></div></div>