[Accepted] A New Direction for Testing in Swift

[0xTim (Tim)]

@grynspan

This is an area we have intentionally not built out yet. We don't want to end up reinventing existing language features just for testing if we can avoid it. Our hope is to leverage async deinit and async throws defer for this sort of functionality (with the understanding that neither feature is actually part of the language yet.)

It would be good to have some guidance from the language team about the direction and timelines for these features. Without these, it pretty much stops Swift Testing being able to be adopted in any server-side Swift framework, package or app

[dannflor (Samuel Bishop)]

@0xTim

It would be good to have some guidance from the language team about the direction and timelines for these features. Without these, it pretty much stops Swift Testing being able to be adopted in any server-side Swift framework, package or app

I believe you can mostly work around this with a CustomExecutionTrait, as it can run async work before and after the test. It's not ideal, but it would mean while we're waiting for to async deinit we could do async setup and teardown as part of each test.

[sspringer (Stefan Springer)]

Question: Being able to insert tests side-by-side to the according implemention that should be tested (right?), is it then possible to test private parts of the code? (I know there is some theory why only the public API should be part of unit tests, but there might be complicated private stuff that one might like to have tests available for.)

[jeremyabannister (Jeremy Bannister)]

@taylorswift

throws is not sufficient for this use case, because there are a lot of constructs in the language (properties, subscripts) that don’t support throws.

Properties and read-only subscripts do support throws:

struct Foo {
    var throwingProperty: Bool {
        get throws {
            return true
        }
    }

    subscript(foo: Int)-> Bool {
        get throws {
            return true
        }
    }
}

[grynspan (Jonathan Grynspan)]

@sspringer

Question: Being able to insert tests side-by-side to the according implemention that should be tested (right?), is it then possible to test private parts of the code? (I know there is some theory why only the public API should be part of unit tests, but there might be complicated private stuff that one might like to have tests available for.)

This is an area we're interested in exploring as a future direction, but it requires compiler and/or linker changes to support it (otherwise you'd end up shipping debug or test code in your build products.)

This is mentioned in our documentation here.

[taylorswift]

learn something new every day!

[macguru (Max Seelemann)]

Just want to chime in that I really like the new framework, its integration into Xcode and the overall direction!

Over the past few weeks, we‘ve started migrating more and more tests from XCTest to swift-testing and the results are promising. Especially async code is much easier and natural to test, that we were able to deprecate quite a bunch of custom helpers.

I’m happy to hear that mocking is on the radar. We use it especially for testing and documenting contracts and calling conventions on component boundaries. We’re not dependent on it, and hacking up a quick dummy implementation for a protocol or delegate is certainly easier in Swift than it was in ObjC, but it’s a nice tool if it makes for less and cleaner code.