[swift-evolution] Solving the issue of unit-testing precondition with the Standard Library?

[Dmitri Gribenko]

On Sat, Mar 12, 2016 at 4:28 PM, Jonathan Tang via swift-evolution
<swift-evolution at swift.org> wrote:
>
>
> On Sat, Mar 12, 2016 at 1:41 PM, David Hart via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> 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.
>>
>> 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.
>>
>> http://stackoverflow.com/a/31349339
>>
>> Is this imaginable?
>
>
> +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.

I completely agree that the approach that uses process isolation is
the right way to go, not just for testing preconditions, but for all
other reasons you mention.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/