By now, you should be familiar with the basics of Test-Driven Development (TDD) and its iterative Red-Green-Refactor cycle. This lesson focuses on honing your TDD mindset, a perspective that prioritizes writing tests before coding, which can dramatically improve code clarity, reliability, and maintainability.

We'll continue using Swift and XCTest, tools that streamline our test-driven approach in Swift projects. Though we use XCTest for its popularity and integration ease, other alternatives exist for different preferences or project requirements.

Let's explore this mindset further with practical examples and visualize the flow of thinking in tests.

Let's begin by writing tests for a function named calculateTotal, designed to compute the total price of items in a shopping cart. This is where you engage with the Red phase: Write a failing test.

Let's think about how to build a function that calculates lists of items. What should the interface be? How does the consumer of the code use it? These are the questions we think about first when we "think in tests." Here's one way we might think about it.

Swift
Copy to clipboard
1import XCTest
2
3class CartTests: XCTestCase {
4    func testCalculateTotalEmptyCart() {
5        XCTAssertEqual(calculateTotal([]), 0)
6    }
7}

Explanation:

• We know we want a function called calculateTotal(), so we'll write a test that uses it.
• For now, we know that we want an empty list as input to return 0, so we can write that test.
• The expectation is that these tests will initially fail, which is an integral part of the Red phase.

Running these tests confirms they fail, creating a clear path for subsequent development.

Now, let’s move to the Green phase, where we implement the minimal code to pass these tests.

Implement the calculateTotal function:

Swift
Copy to clipboard
1func calculateTotal(_ items: [Any]) -> Double {
2    return 0
3}

Explanation:

• The calculateTotal function takes a list of items. We don't really know the shape of the data yet, and that's OK!
• Returning 0 is enough to get the test to pass.

By running the test suite again, we should see all tests passing, demonstrating that our function meets the required condition.

In the Refactor phase, we fine-tune the code for clarity and performance. It's always OK to do nothing in this step, and that's what we'll do. Let's add another test.

Now is the time to think about what kind of data we want to pass to our calculateTotal function. We consider that we'd like to pass the name, price, and quantity as properties of a struct in the list. The total will be the product of price and quantity. Let's do that and see how it feels:

Swift
Copy to clipboard
1struct Item {
2    let name: String
3    let price: Double
4    let quantity: Int
5}
6
7class CartTests: XCTestCase {
8    func testCalculateTotalEmptyCart() {
9        XCTAssertEqual(calculateTotal([]), 0)
10    }
11
12    // New test
13    func testCalculateTotalForSingleItem() {
14        let items = [Item(name: "Apple", price: 0.5, quantity: 3)]
15        XCTAssertEqual(calculateTotal(items), 1.5)
16    }
17}

That feels pretty good; the interface seems clear. Let's see if we can get those tests passing.

Now, we need to think about how to make these tests pass. What is the minimum necessary to get this to pass?

Swift
Copy to clipboard
1func calculateTotal(_ items: [Item]) -> Double {
2    if items.count > 0 {
3        return items[0].price * Double(items[0].quantity)
4    }
5    return 0
6}

When we run the tests, we should see that both tests pass! We're Green!

Now we ask ourselves: is there anything we can do to make this code better? One thing I might do is get rid of the repetition of items[0] in the calculateTotal function. Another thing I might do is define a more structured type using a class for the items.

Swift
Copy to clipboard
1func calculateTotal(_ items: [Item]) -> Double {
2    if items.count > 0 {
3        let item = items[0]
4        return item.price * Double(item.quantity)
5    }
6    return 0
7}

When we run the tests again, we're still green. The code is more expressive now and has a better structure, so let's do the Red-Green-Refactor loop again!

The existing code works! But it won't be very useful to only use the first item. If we add one more test, we can generalize more.

Swift
Copy to clipboard
1class CartTests: XCTestCase {
2    func testCalculateTotalEmptyCart() {
3        XCTAssertEqual(calculateTotal([]), 0)
4    }
5
6    func testCalculateTotalForSingleItem() {
7        let items = [Item(name: "Apple", price: 0.5, quantity: 3)]
8        XCTAssertEqual(calculateTotal(items), 1.5)
9    }
10
11    func testMultipleItems() {
12        let items = [
13            Item(name: "Apple", price: 0.5, quantity: 3),
14            Item(name: "Banana", price: 0.3, quantity: 2)
15        ]
16        XCTAssertEqual(calculateTotal(items), 2.1)
17    }
18}

As expected, this new test will fail, and we can move to the Green step.

Let's take a stab at getting the test to pass:

Swift
Copy to clipboard
1func calculateTotal(_ items: [Item]) -> Double {
2    var total = 0.0
3    for item in items {
4        total += item.price * Double(item.quantity)
5    }
6    return total
7}

This does the job, and we're Green again. I can't help but feel like we could have written that code a bit better. Now that we have tests that cover everything we want this function to do, let's move to the Refactor step!

When we look at the calculateTotal function, it is clear that this is an "aggregate function." It takes a list of items and reduces it to an aggregate value. Times like this call for higher-order functions!

Swift
Copy to clipboard
1func calculateTotal(_ items: [Item]) -> Double {
2    return items.reduce(0) { $0 + $1.price * Double($1.quantity) }
3}

The reduce function here achieves the goal of aggregation succinctly. I like this code a lot better! Best of all, our tests tell us that we're still Green! We've successfully refactored the code.

Running the tests one more time shows we're still Green! In Xcode, you can run the tests by selecting the test navigator and clicking the play button next to your test class or individual test methods.

Throughout this lesson, we delved into adopting a TDD mindset with a focus on writing tests before coding and following the Red-Green-Refactor cycle meticulously. Here are your key takeaways:

• Red: Start by writing a failing test. This ensures you have a clear goal and define the interface upfront.
• Green: Develop just enough code to pass the test, ensuring you fulfill the requirements.
• Refactor: Optimize your code for readability and maintainability, all while ensuring tests continue to pass.

These principles set a solid foundation for the upcoming practice exercises, further cementing this mindset into your development workflow. Continue practicing the TDD cycle to foster robustness, code clarity, and reliability in your projects. Keep going, and embrace TDD as an essential part of your coding journey.