<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>As I'm not technically <span style="background-color: rgba(255, 255, 255, 0);">knowledgable enough </span>in low-level process handling and about the intricacies of xctest, I can't write a proposal that stands on it's own feet. All I can do is talk about it until someone that is can work on it.</div><div><br>On 13 Mar 2016, at 20:36, Goffredo Marocchi <<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I think keeping the code running in a separate process with probes may be something really useful in the unit testing toolbox for sure. How far did your experiment/proposal with that went?<br><br>Sent from my iPhone</div><div><br>On 13 Mar 2016, at 14:27, Step C via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>I think the forking approach is correct and would like to see more tooling support for that path in test runners. </div><div><br>On Mar 13, 2016, at 5:20 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Okay, perhaps this is not the optimal solution. But I tried to rally enthusiasm for finding a solution using forks a few months back and the complexity of the problem seemed to stall the progress. The issue is important enough for me that I tried to come at it from a different angle. If be more than happy if it was implemented using forks.</div><div><br>On 13 Mar 2016, at 01:28, Jonathan Tang <<a href="mailto:jonathan.d.tang@gmail.com">jonathan.d.tang@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 12, 2016 at 1:41 PM, 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">I am deeply interested in finding solutions for allowing unit-tests of preconditions. Without them, I believe we are leaving many holes in our tests and coverage. The solution found in the Swift project of forking the process seems fairly complicated to implement in XCTest.<br>
<br>
I found a solution online that works by overriding the precondition function with a function that calls a configurable closure which defaults to the original precondition function. It would be great if the Standard Library allowed this by default so that XCTest could use it to offer full support for precondition unit tests.<br>
<br>
<a href="http://stackoverflow.com/a/31349339" rel="noreferrer" target="_blank">http://stackoverflow.com/a/31349339</a><br>
<br>
Is this imaginable?<br></blockquote><div><br></div><div>+1 to this being an important problem to solve, but I'm not sure about the specific solution. Are there performance or security impacts to production code by having this? Could the forked-process solution be implemented once in a framework and then everybody just uses it transparently? The forked-process approach also has the advantage of catching crashes for any other unexpected reason (eg. division by zero), and of ensuring that test executions are hermetically sealed without data leaking between test instances.</div></div></div></div>
</div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></body></html>