One of the first things I learned as an iOS developer was to avoid using (!) as much as I could. After all, they were as dangerous as they were convenient - you don't want your app to crash in your user's hand, do you? force unwraps That's why I never really liked how Apple instructs us to do our unit tests using the XCTest framework. It would be something like this: 😤 The ugly way final class PlayerListManagerTests: XCTestCase {
    private var sut: PlayerListManager!

    override func setUp() {
        // This will run before each test
        sut = PlayerListManager()
    }
    
    override func tearDown() {
        // This will run after each test
        sut = nil
    }

    func test1() {
        let player = PlayerModel(id: 0, name: "Diego Maradona")
        sut.add(player)

        XCTAssertEqual(1, sut.list.count)
        XCTAssertEqual(player, sut.list.first)
    }

    func test2() throws {
        let player = PlayerModel(id: 0, name: "Edson (Pelé))
        sut.add(player)

        let auxPlayer = try XCTUnwrap(sut.getPlayerFrom(index: 0))
        XCTAssertEqual(player, auxPlayer)
    }
} As you can see, our is a non-optional instance variable. This means we do not have to initialize it along with our class, but if we try to access it before it has been created our application will crash. However, we are making use of two very important methods: sut : This will be called before we execute each one of our tests. This means, before we execute either or , we will call the setUp and then our will be created and we won't have problems accessing it. setUp test1 test2 method, sut : This will be called after each test is executed. This means that after we execute either or , we will call the method and our will be deinitialized. Since we are done using it, there is no problem with removing it from our memory. tearDown test1 test2 tearDown sut So, it means that before we execute each one of our tests we are going to create our objects and after we finished using them we clean everything, so we can move on for our next test. Right? Well, kinda. Actually, what we've discovered after some time is that for each test, Xcode will create a new instance of our test class. So when we are going to run , an instance of will be created. Then, when we move on to , another instance of will be initialized. test1 PlayerListManagerTests test2 PlayerListManagerTests Therefore, it doesn't matter if we create our objects and clean them after the test. Since we are going to be using different instances of our class, we could very well do some things like this: 😍 The beautiful way final class PlayerListManagerTests: XCTestCase {
    private let sut = PlayerListManager()

    func test1() {
        let player = PlayerModel(id: 0, name: "Diego Maradona")
        sut.add(player)

        XCTAssertEqual(1, sut.list.count)
        XCTAssertEqual(player, sut.list.first)
    }

    func test2() throws {
        let player = PlayerModel(id: 0, name: "Edson (Pelé))
        sut.add(player)

        let auxPlayer = try XCTUnwrap(sut.getPlayerFrom(index: 0))
        XCTAssertEqual(player, auxPlayer)
    }
} As you can see, there is no need for and . And it's true, the code above will work. And it looks a lot better since we are not using and we're writing less code. setUp tearDown force unwrap, However, the above has a big and dangerous downside. 😰 The reality Now, we know that Xcode created a lot of instances, one for each of our tests. Can you guess what would happen if these instances were not removed from memory after they run? What if they were kept in memory until the tests have finished? PlayerListManagerTests all Well, if you guessed something like “all the objects we created will still be allocated and consuming space in memory", then you're right. And guess what, this is exactly what happens. Xcode won't clean our classes and our objects until all our tests have finished. 💩 The problem Surprised? Well, I was too the first time I heard about it. So, can you see what would happen if we had a lot of tests and a lot of objects? ! We would be also using a lot of memory, maybe more than we actually have. Of course, it may be hard to achieve a stage where our machine would stop working because there is no memory left. However, we should be aware that it can happen and understand that and are not as useless as they look at first sight. Touché setUp tearDown So, how are you going to write your tests from now on? Do you think this memory downside is great enough for you to care? Or maybe you have not even started writing your unit tests? 😏

Apple

Initialized

Nominated for 2022 - HackerNoon Contributor of the Year - Swift

Nominated for 2022 - Ios Writer of the Year

Too Long; Didn't Read

Make resilience your competitive advantage

Swift XCTest: setUp and tearDown Are Not Dead Yet

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

105 Stories To Learn About Ios App Development

10 Things You Didn't Know You Could Do With Google Keep

118 Stories To Learn About Mobile

The Noonification: Craig Wright Is NOT Satoshi Nakamoto (12/19/2023)

25 Common iOS 16 Issues

105 Stories To Learn About Ios App Development

10 Things You Didn't Know You Could Do With Google Keep

118 Stories To Learn About Mobile

The Noonification: Craig Wright Is NOT Satoshi Nakamoto (12/19/2023)

25 Common iOS 16 Issues

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps