<div dir="ltr">+1 from me. I&#39;m really annoyed by the fact I can&#39;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&#39;s promise to be safe for example. If you can&#39;t test the behavior in cases where an array index was used which is out of bounds then you can&#39;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">&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">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&#39;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&#39;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>