In this episode, we dive into XCTestCase’s lifecycle and show different ways for configuring your system under test.

XCTest, similarly to JUnit, invokes each test method on a separate instance of the test case. To illustrate with an example, imagine that you have ten test methods, the XCTest framework will instantiate ten instances of the test case class and invoke only one of the methods per instance. We believe this is a good design choice, as by running the test methods in separate instances we can avoid sharing state between tests. However, XCTestCase’s behavior isn’t that obvious which can make it counterintuitive when compared with how we're used to using objects to share state between methods.

Swift Factory methods

Although the setUp/tearDown configuration method is valid, at Essential Developer we noticed that moving configuration code to factory methods would yield better results in most cases.

Here are the main reasons why we prefer factory methods over the setUp/tearDown configuration:

1. Many tests have a different setup/configuration, so there are no significant benefits in sharing the object instantiation.

2. We normally use constructor injection. If we create a class as a property in the class scope, we would have to use property injection to be able to configure the instance for each test. Which is fine too, but we prefer constructor injection since most of our classes don’t allow mutability.

3. We want to test the whole lifecycle of the system under test instance, to guarantee there are no issues when it's removed from memory. We could achieve this with the setUp() approach, but to test the whole lifecycle we would also need to set it to nil in the tearDown(). By creating the instance in the test method scope, we guarantee its lifecycle is tested within the method (since the instance will be freed automatically).

4. It would take more lines of code to do the same thing and, in our opinion, it would negatively impact the design of the test and the production code (e.g., constructor->property injection).

5. setUp/tearDown can make the tests harder to read/understand since, when reading the code, we would have to scroll/jump scope (from test method to setUp/tearDown code) to understand the whole context. We prefer to keep our test setup (Given/When/Then or Arrange/Act/Assert) in the shortest scope possible.

When we use XCTestCase setUp/tearDown in Swift

To be clear, we avoid setUp/tearDown configuration because we believe there are better ways, but we do use it when it's useful to us.

For example, setUp/tearDown can be useful when dealing with global state (e.g., databases) that needs to be restated for each test (as we don't want to pollute the test methods with those details).