Example

Imagine a profile database, that can create a new profile for you.

final class ProfileDatabase {
    func create(_ profile: Profile) -> String {
        return "🥳 profile has been created!"
    }
}

When you're creating one, all that's required is providing the first name. Everything else? That's, completely optional.

struct Profile {
    let firstName: String
    let lastName: String?

    let email: String?
    let phoneNumber: Int?

    let image: URL?
}

To ensure our profile database works as intended, let's explore the various use cases, we have to cover with our tests.

1. Just the first name.

2. First name and last name.

3. First name, last name, and email.

4. First name, last name, email, and phone number.

5. And finally, everything.

Common way

For these five use cases, we create a brand-new test method for each one of them.

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfileWithOnlyFirstName() throws {
    let profile = Profile(
        firstName: "John",
        lastName: nil,
        email: nil,
        phoneNumber: nil,
        image: nil
    )

    let message = sut.create(profile)

    XCTAssertEqual("🥳 profile has been created!", message)
}

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfileWithOnlyFirstNameAndLastName() throws {
    // Test Code ...
}

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfileWithOnlyFirstNameAndLastNameAndEmail() throws {
    // Test Code ...
}

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfileWithOnlyFirstNameAndLastNameAndEmailAndPhoneNumber() throws {
    // Test Code ...
}

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfileWithAllArguments() throws {
    // Test Code ...
}

As you take a closer look:

• For each use case, you'll need a brand-new test method.

• Long method names can get confusing.

• Code that repeats itself unnecessarily.

A better solution: Parameterized Tests

Alright, let's dive into Parameterized Tests!

But first, what exactly is it?

Well, it's nothing more than writing a test that runs a piece of code repeatedly, but each time with a different input. This, in turn, leads to a different output.

In other words, you can cover multiple use cases within a single test.

Step 1:
To begin, we need to create a generic struct that can handle any type of input and output. So we can use it in any test with different input and output.

struct TestCase<Input, Output> {
    let input: Input
    let output: Output

    private let line: UInt

    init(
        input: Input,
        output: Output,
        line: UInt = #line
    ) {
        self.input = input
        self.output = output
        self.line = line
    }

    func message() -> String {
        return "🚨 Failed on line: \(line)"
    }
}

Step 2:
After creating the generic struct, we can use it.

Just create one test, and we're good to go!

func test_returnProfileHasBeenCreatedMessage_whenCreatingProfile() throws {
    [
        TestCase(
            input: Profile(
                firstName: "John",
                lastName: nil,
                email: nil,
                phoneNumber: nil,
                image: nil
            ),
            output: "🥳 profile has been created!"
        ),

        // Remaining 4 Test Cases ...

    ].forEach { testCase in
        XCTAssertEqual(
            testCase.output,
            sut.create(testCase.input),
            testCase.message()
        )
    }
}

Benefits

This has a few key benefits:

1. Code Reusability: Write it once and use it with countless inputs - say goodbye to repetitive test code!

2. Readability: No more lengthy test method names. Everything's crystal clear and concise.

3. Input-Output Clarity: Clear input-output relationship.

4. Scalability: As your code grows, adding new use cases is a piece of cake. Keep that test suite up-to-date!

Food for thought

Did you find this article helpful? Go ahead and give that 🤍 like button a tap.
Your appreciation fuels my motivation to keep bringing you more content 💪.

If you have suggestions or improvements, feel free to share them in the comment section. Let's all learn new ways together!

Resources

The example code in this article is right here, ready for you to delve into, learn from, and, ultimately, start applying in your own tests.

To get a firsthand look at how we've shifted from the Common Way to Parameterized Tests, explore the commits.

References

Reid, J. (2021, February 28). Parameterized Swift Tests in XCTest (Live Coding). YouTube. https://www.youtube.com/watch?v=_RiEvcHl3_c

Wake, B. (2020, November, 25). Parameterized Unit Testing. XP123. https://xp123.com/articles/parameterized-unit-testing

Common way

One common way is creating test data via a constant.

let restaurantWithOnlyName = Restaurant( 
    name: "Delicioso food", 
    cuisines: nil, 
    rating: nil 
)

And when you need to test a different use case. You need to create a new one.

let restaurantWithOnlyNameAndRating = Restaurant(
     name: "Delicioso food",
     cuisines: nil,
     rating: 5.0
)

Soon you have many constants. Making it hard to maintain.
Imagine you need to:

• Change a property name

• Add a new property

• Delete a property

You have to update not only one but all of them.

A better solution: The Builder pattern

There are better ways of creating test data. Among them is the Builder pattern. Creating objects step by step, using a builder class.

Step 1:
To start with, every property has a default value.

class RestaurantBuilder {
    private var name: String = "Delicioso food"
    private var cuisines: [String]? = ["Seafood"]
    private var rating: Double? = 5.0
}

Step 2:
Second, every property’s value is changeable via a with(:) method.

class RestaurantBuilder {
    private var name: String = "Delicioso food"
    private var cuisines: [String]? = ["Seafood"]
    private var rating: Double? = 5.0

    func with(name: String) -> Self {
        self.name = name
        return self
    }

     func with(cuisines: [String]?) -> Self {
        self.cuisines = cuisines
        return self
    }

     func with(rating: Double?) -> Self {
        self.rating = rating
        return self
    }
}

Step 3:
And finally a build(:) method to construct the object using those values.

class RestaurantBuilder {
    private var name: String = "Delicioso food"
    private var cuisines: [String]? = ["Seafood"]
    private var rating: Double? = 5.0

    func with(name: String) -> Self {
        self.name = name
        return self
    }

     func with(cuisines: [String]?) -> Self {
        self.cuisines = cuisines
        return self
    }

     func with(rating: Double?) -> Self {
        self.rating = rating
        return self
    }

    func build() -> Restaurant {
        return Restaurant(
           name: self.name,
           cuisines: self.cuisines,
           rating: self.rating
        )
    }
}

Step 4:
After creating the builder class, we can use it.

When we are testing a use case, where the exact values of the properties don't matter, we can use the default values.

let restaurant = RestaurantBuilder().build()

And when we are testing a use case, where the exact values of the properties matter, we can change the default values.

let restaurant = RestaurantBuilder()
    .with(name: "Awesome Delicioso food")
    .build()

Benefits

• Creating test data is made simple: It's fast and easy.

• Keeping things maintainable: If the model changes, we only have to update the builder class. All the configuration takes place there.

• Highlighting only what matters: You only change the values of the properties that matter. Removing all distractions.

// Create Restaurant with 5.0 star rating
let restaurantWithFiveStarRating = Restaurant(
     name: "Delicioso food",
     cuisines: nil,
     rating: 5.0
)

let restaurant = RestaurantBuilder()
    .with(rating: 5.0)
    .build()

Complex data

Data can be(come) complex. Imagine we want to provide the location of a Restaurant.

struct Location {
    let address: String?
    let zipCode: Int?
    let city: String?
    let country: String?
}

struct Restaurant {
    let name: String
    let cuisines: [String]?
    let rating: Int
    let location: Location?
}

We have to update our RestaurantBuilder to conform to this new change. To make this happen, we need to create a new builder class, LocationBuilder for the model Location. Then we will use this for setting the default value for the location property.

class RestaurantBuilder {
    private var name: String = "Delicioso food"
    private var cuisines: [String]? = ["Seafood"]
    private var rating: Double? = 5.0
    private var location: Location? = LocationBuilder().build()

    func with(name: String) -> Self {
        self.name = name
        return self
    }

     func with(cuisines: [String]?) -> Self {
        self.cuisines = cuisines
        return self
    }

     func with(rating: Double?) -> Self {
        self.rating = rating
        return self
    }

   func with(location: Location?) -> Self {
        self.location = location
        return self
    }

    func build() -> Restaurant {
        return Restaurant(
           name: self.name,
           cuisines: self.cuisines,
           rating: self.rating,
           location: self.location
        )
    }
}

Food for thought

Did you find this article helpful? Go ahead and give that 🤍 like button a tap.
Your appreciation fuels my motivation to keep bringing you more content 💪.

If you do have other ways of creating test data, feel free to share them in the comment section. Let's all learn new ways together!

References

Steve Freeman, S., & Nat Pryce, N., 2009. Growing Object-Oriented Software, Guided by Tests