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
+1 from me. I'm really annoyed by the fact I can't reach 100% code coverage
due to this :)
Being able to test them is very valuable. 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 th
I think that there’s a lot of room for improvement in how we measure and
analyze perf test results. And I like some of your ideas of adaptive numbers of
runs and what to do with outlier results, etc… that you presented below.
We would very much like to not diverge the API of the CoreLibs XCTest
Tony, all:
I went back to basics and used the following to build:
./swift/utils/build-script -R --xctest --foundation -t
Unfortunately I get the same result - missing symbols for enumerations in
libFoundation.so. Once again I'm building against the master branch for
all repositories.
I'm going
> On Dec 13, 2015, at 2:03 AM, David Hart via swift-evolution
> wrote:
>
> 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?
I’m curious why it’s these particular enums are different. If you try to build
a sample app that actually uses these enum values, does it fail to link?
- Tony
> On Dec 13, 2015, at 9:19 AM, Joseph Bell wrote:
>
> Tony, all:
>
> I went back to basics and used the following to build:
>
> ./swi
