<div dir="ltr">+1 from me. I'm really annoyed by the fact I can't reach 100% code coverage due to this :)<div><br></div><div><font face="arial, helvetica, sans-serif">Being able to test them is very valuable. </font><span style="font-family:arial,helvetica,sans-serif">Take Swift's promise to be safe for example. If you can't test the behavior in cases where an array index was used which is out of bounds then you can't test even the promise to be safe.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 11:03 AM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently, it is impossible for XCTest to unit test assert and precondition failures because they kill the process. And those are important to unit test: how would you test NSArray's objectAtIndex bound conditions? Currently, the standard library tests those with StdlibUnittest, a small piece of code which runs those tests in a forked process.<br>
<br>
I want to start a proposal but I'm not sure if it should come as a XCTest improvement which spawns a process or if the language should implement assert and precondition as a special kind of throw?<br>
<br>
David<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</blockquote></div><br></div>