Test-Driven Development (TDD) for bug fixes in Swift

Test-driven development (TDD) is a technique that requires you first to write a failing test before you start implementing a solution. While it’s a technique developers use during general development, there’s a way to apply it only for bug fixes.

Finding out about a bug can already be disappointing, but finding out about a bug that re-occurred will be even worse. It’s an essential development skill to prevent a bug from returning after you’ve once fixed it.

A New Pair Programming Tool for XcodePair programming in Xcode is difficult. Stop struggling to describe which line of code to change or dancing around who’s screen sharing. With Multi, simply point, draw, or even take control of your teammate’s Xcode. Multi just launched into early access, so be the first to try it out!

What is Test-Driven Development (TDD)?

The Test-driven development (TDD) process requires you to write a failing test before you start implementing the solution. You can use it to define all specifications for a new feature and ensure you do not forget about any expected outcomes.

For example, imagine having the following article struct:

struct Article {
    let title: String
    let author: String
    let link: URL
}

We might want to create a new computed property to return the blog domain for this article. Before diving into writing the actual computed property, we would first define the following test case:

func testArticleDomain() {
    let article = Article(
        title: "Async await in Swift explained with code examples",
        author: "Antoine van der Lee",
        link: URL(string: "https://www.avanderlee.com/swift/async-await/")!
    )
    
    XCTAssertEqual(article.blogDomain, "avanderlee.com")
}

This code will not compile since the blogDomain property doesn’t exist. Since we want the test to fail first, we can add a computed property that returns an empty string:

extension Article {
    var blogDomain: String {
        ""
    }
}

We can now successfully run the unit test and conclude that it indeed fails:

Finally, we implement the actual logic, and re-run the test to ensure it succeeds:

extension Article {
    var blogDomain: String {
        link.host()?.replacingOccurrences(of: "www.", with: "") ?? ""
    }
}

The workflow looks similar to what many developers do, but the main difference is starting by writing a test instead of jumping directly into feature development.

Benefits of TDD

Developers tend to hesitate to start using test-driven development in their workflow. It feels redundant to write a failing test and a waste of time. Before I start listing a few benefits of TDD, I think it’s important to emphasize you can use this technique as an opt-in toolset when it fits your current task.

I use it occasionally when I want to clear my mind of expected outcomes. By writing tests, you ensure you’ll remember all edge cases and expected outcomes. Secondly, you’ll enable yourself to focus entirely on developing the solution without having to think about the outcomes you have to support constantly: you can run the tests and know that you’re done when they all succeed.

Another benefit of writing failing tests first is to ensure your test actually fails. This sounds stupid, but I’ve seen many tests that would always succeed, even if the implementation changed. In other words, the test wouldn’t catch any wrong implementations.

Lastly, by starting with tests, you’ll ensure your new code becomes testable from the start. When you write new code without tests in mind, writing tests afterward is likely more challenging. Since it becomes harder, it’s easier to skip writing tests at all, resulting in lower test coverage.

The win-wins of solving bugs using tests

The main reason I started writing about Test-driven development is that I’m using it mostly when I’m solving bugs.

Reproducing a bug using a test instead of manual interactions

When I start solving a bug, I first want to know how to reproduce it. The first thing you might do is open your application and start navigating around. However, in my experience, looking at the specific code and writing a test with a similar input as the bug report states is much easier. Ideally, you’ll have enough logs (for example, by using Diagnostics) to know what’s causing the bug. If not, you could read the specific lines of code and use a test to find the trigger.

An extra benefit of writing the test is that you’ll likely better understand the cause of the bug. It won’t surprise me if you’ll be able to solve the bug faster as well. Therefore, TDD works great together with bug fixes.

Solving a bug with the test in place

Once you have the test in place, you can start solving the bug. Depending on the bug, this can be challenging and time-consuming. Having a way to quickly validate your solution can drastically improve the time to fix it. Instead of having to manually perform all kinds of steps, you can simply re-run the test and validate.

I’ve seen developers solving bugs using manual app interactions, where they weren’t even able to reproduce the bug constantly in the first place. In other words, with a bit of luck, you think you solved the bug while you actually didn’t. It’s essential to have a constant reproduction in place before you can consider a fix to be solid.

Higher code-coverage and more confidence

Once you’ve solved the bug, you’ve implemented a new test and increased code coverage simultaneously. You can also be more confident about your codebase as you’ve ensured the bug can’t return without failing your test. Codebase confidence can not be underestimated and is crucial for apps that want to ship updates regularly to a large audience.

Screenshare done right—and everything else too.We can't fix Xcode's random bugs for you, but we can at least make it easier to pair in. Multi is a new video tool that lets anyone point, draw and even type in your Xcode—or any other app. When you work in Multi it automatically takes notes, including what files you looked at. Try it out for free!

Conclusion

Test-driven development is a great technique to increase your test code coverage while increasing your code quality at the same time. It can be tedious to write failing tests at first, but the result will be a more complete feature implementation that covers all expected outcomes. When used in combination with bug fixing, you’ll improve your confidence and ensure a bug won’t return in the future.

If you like to improve your workflow, even more, check out the workflow category page. Feel free to contact me or tweet to me on Twitter if you have any additional tips or feedback.

Thanks!