Should we start using Swift Testing?

General
,
1

The new framework has been out quite a while, and I thought it might be a good idea to start rolling it out in our codebase.

My only concern is that as we start parallelizing things, we’ll increase the flakiness since we made architectural decisions in the past, like asserting a given output has been printed, which relies on global states.

What if we do the following:

  1. If the test depends on the global state, we run it serially:
@Test(.serialized) func prepare(food: Food) {
}
  1. Otherwise, we don’t add the .serialized annotation, which means it runs in parallel by default.

It might not be trivial to tell if a piece of logic depends on the global state. Still, as we detect it, we can either turn the test into a parallel test or take the opportunity to propose alternative patterns and move away from the global state (at the cost of compromising the ergonomy of the code with a bit of dependency injection).

Thoughts?

2

I’m definitely onboard with using the new Swift Testing – being up-to-date with Apple’s tooling means we dogfood the usage of these new features with Tuist.

I think I’d lean to enabling/disabling parallelization at a target level as that will make it easier to reason about things and only disabling parallelization at a test case level on rare occasions.

Most of our unit tests actually don’t use any global state (apart from TuistKitTests that often test the output), so I’d expect those not to be flaky when run in parallel. All of the acceptance should still run serialized as they all depend on global state.

3

Sounds awesome! Let’s do it then :wink: