XCTest + Swift: setUp/tearDown vs Factory Methods

★ Register Now to Our Free iOS Career Course! https://www.essentialdeveloper.com/co... Subscribe to our channel: https://www.youtube.com/essentialdeve... • XCTest repo on GitHub https://github.com/apple/swift-coreli... • QuizApp repo on GitHub https://github.com/essentialdeveloper... 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 to 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). Conclusion We would like you to be proactive and think about the problems you're facing so you find the best solution for you. For example, our approach could be wrong for you, so be critical and let us know your preferred way. ★ Professional iOS Engineering S01 Take your skillset to the next level and boost your career https://www.essentialdeveloper.com/pr... ★ Download our new app You can download Neat Trivia from the App Store today at https://itunes.apple.com/app/id125311.... Connect with us on: • Website: https://www.essentialdeveloper.com • Twitter:   / essentialdevcom   • Facebook:   / essentialdeveloper