Policiano

How do I name my test methods?

Will Policiano — Sat, 29 Oct 2022 20:02:41 GMT

Hello there! It's great to be back here, ready to dive into unit testing again. Today, I want to share some valuable techniques that I personally use to give effective names to my unit test methods. Naming things can be a challenge for many developers, including myself. Whether it's classes, variables, functions, or methods, finding the right name often requires some extra thought. And when it comes to unit tests, this challenge becomes even more apparent.

The Problem

I've found myself spending more time brainstorming a good name for my test than actually writing the test itself. It's essential to strike a balance between expressing the test's intent and keeping the name concise and easy to read. After all, when someone reviews your code or looks at the CI log, they want to understand the test's purpose quickly. So, in this post, I'll share some techniques that may come in handy when you face this naming dilemma.

But before we get into the techniques, let's talk about some conventions and patterns that can make your test names more consistent and comprehensible, especially when working in larger teams.

Conventions and Patterns

To start, it's helpful to establish a consistent pattern or template for naming your test methods. Having a standardized format benefits everyone involved. It enables developers to understand each other's code more easily and write new code faster. Here are a couple of aspects to consider

Line length

Nobody enjoys scrolling horizontally through code, especially during code reviews or when reading a CI log. So, I strongly recommend setting a maximum line length for your method names. Long test names can be a sign of underlying issues, such as complex setups or obscure conditions. It's an opportunity to reassess the design of the subject being tested.

You can choose a suitable line length for your project, but I suggest aiming for a range between 90 and 130 characters. This ensures that your test names fit comfortably on a GitHub page without requiring line breaks or horizontal scrolling. To make it easier to adhere to this restriction, you can enable the page guide in your editor. In Xcode, go to Xcode > Preferences > Text Editing and check the "Page guide column" option.

Once enabled, the page guide will be visible in your editor, helping you stay within the desired line length.

Formatting

Deciding on a consistent format for your test names is crucial. You can choose from lowercase, uppercase, camel-case, or snake-case—whatever works best for your project. Personally, I start my test names with the test_ prefix.

It's also helpful to adopt a specific casing pattern for your method names. I prefer using lower-camel case, where each word starts with a lowercase letter except for the first word. Here's an example to illustrate the point:

✅ Do:

func test_deselectsItemUponSecondTap()

🛑 Don’t:

// Doesn't have the defined underscore
func testDeselectItemUponSecondTap()

// Snake case
func test_deselect_item_upon_second_tap()

// Mixed cases
func test_deselectItem_uponSecondTap()

You might wonder why I recommend adding an underscore (_) after the test prefix. This practice serves a specific purpose—to separate the test keyword from the test's intent, which will be explained in more detail in the next section.

By introducing this visual separation, we create a clearer distinction between the standardized test prefix and the descriptive part of the test name. It enhances readability and makes it easier for developers to quickly identify that a method is a test method.

Once you've established these conventions and patterns, you're ready to move on to the next step.

Expressive Test Summaries

A well-crafted test name should provide a concise summary of what is being tested. This is the most challenging part, but here's a useful approach to consider. Imagine you're writing a commit message, and try to complete the following sentence:

"This test ensures that the SUT (System Under Test) ...

Let me give you a few examples:

... deselects an item upon a second tap."

... shows content on a successful response."

... returns the preferred payment method."

... completes with a not-found error on invalid URLs."

Keep it simple. Just complete the sentence using the Simple Present tense. By doing this, you focus on the behavior or functionality of the SUT without including details about spies, collaborators, class names, or implementation specifics. This approach makes your tests more flexible when it comes to refactoring.

To comply with the line length restrictions, you may need to omit some article words. Remember, the goal is to create test summaries that are clear and concise.

✅ Do:

func test_showsContentOnSuccessfulResponse()

func test_returnsPreferredPaymentMethod()

func test_completesWithNotFoundErrorOnInvalidURLs()

🛑 Don’t:

// Unecessary verbosity
func test_givenASuccessfulResponseWhenTheScreenAppearShouldShowSomeContent()

// Past tense
func test_returnedPreferedPayment()

// Too coupled with implementation details
func test_completesWith404ErrorFromTheNetworkingForURLRequestsWithInvalidURLs()

Conclusion

These are some of the standards and techniques that have proven effective in my unit tests. They have greatly helped both my team and me, and I hope they can do the same for you. Of course, keep in mind that this post reflects my personal opinions and experiences, so feel free to adapt these techniques to fit your specific context. Thank you for taking the time to read this post! Until next time!

Make your tests cleaner using the Fixture Pattern

Will Policiano — Wed, 02 Feb 2022 02:07:14 GMT

Every unit test has an arrangement step where we set up the test preconditions. In this step, we often need to provide some input objects to the subject under test.

Providing these objects can become pretty verbose and painful to write. Let's see some example:

func testValidateOrder_deliversErrorOnEmptyOrder() {
    let emptyItems: [Item] = []
    let anySeller = Seller(uuid: "any UUID", name: "any name", websiteUrl: URL(string: "http://any-url.com")!)
    let order = Order(uuid: "any UUID", date: Date(), items: emptyItems, totalPrice: 0.0, discount: 0.0, seller: anySeller)

    let actualResult = sut.validate(order: order)

    XCTAssertEqual(actualResult, OrderValidationError.emptyOrder)
}

This is a simple method that validates an order. In this case, orders without items are not allowed and are expected to return an error. Look how verbose and hard to understand this method became. The cause of it is the complexity of the arrangement. To perform the validate(order:) we need to create an Order, which is not a trivial object. Also, the Order object is not an test double but an actual system object type.

Therefore, to improve it, we need to make our test cleaner and focused on what matters by abstracting the object creation and simplifying the arrangement step. We can do it with Fixtures.

Fixtures

Before all, compare the previous example with this new one:

func testValidateOrder_deliversErrorOnEmptyOrder() {
    let order = Order.fixture(items: [])

    let actualResult = sut.validate(order: order)

    XCTAssertEqual(actualResult, OrderValidationError.emptyOrder)
}

Much cleaner, uh? I could abstract the Order creation and focus on what really matters: Setting up an empty order.

This kind of abstraction is called fixture and we can find a great formal definition for test fixtures on the JUnit 4 documentation:

A fixed state of a set of objects used as a baseline for running tests. The purpose of a test fixture is to ensure that there is a well-known and fixed environment in which tests are run so that results are repeatable.

In other words, a fixture is a good way to ensure good code readability on abstracting objects creation. Let's see how to implement it in Swift.

Implementing a Fixture

Because creating fixtures is related to testing purposes, it's recommended to implement it in the Test target. I will use this file naming:

Order+Fixtures.swift

Now we can add extensions to our objects and create the fixture this way:

extension Order {
    static func fixture(
        uuid: String = "", 
        date: Date = Date(timeIntervalSince1970: 0), 
        items: [Item] = [], 
        totalPrice: Decimal = 0.0, 
        discount: Decimal = 0.0, 
        seller: Seller = .fixture()
    ) -> Order {
        return Order(
            uuid: uuid,
            date: date, 
            items: items, 
            totalPrice: totalPrice, 
            discount: discount, 
            seller: seller
        )
    }
}

extension Seller {
    static func fixture(
        uuid: String = "",
        name: String = "",
        websiteUrl: URL = .fixture()
    ) -> Seller {
        return Seller(
            uuid: uuid,
            name: name,
            websiteUrl: websiteUrl
        )
    }
}

extension URL {
    static func fixture(string: String = "") -> URL {
        return URL(fileURLWithPath: string)
    }
}

Simple as that, but we need to consider some things in my implementation:

Note that I created a new fixture recursively for each dependency. It's up to you. Create fixtures as you go and feel that it's needed
I created every fixture in a single file by convenience. You can separate them into different files if you want. No problem.
Double attention to the default values. Aways prefer using empties, zeroes and non-failable values on fixtures default values. Otherwise, we can be lead to flakiness, especially when working with Date.
Why not a convenience init? Using a convenience init wouldn't work because you will be creating a new init with the same argument labels that you defined on the production code, and the compiler will complain about it. On the other hand, using the fixture term tells the reader the code is getting a test value more explicitly.

Conclusion

This was a short tip on how you can make your tests cleaner by arranging the test cases with Fixtures. The way I implemented is a humble suggestion to inspire you. Put it in practice. I strongly believe that it will bring you awesome results. There are a bunch of more techniques to write better tests I will explore with you during this year, so stay tuned. See ya!

References:

What should I test?

Will Policiano — Sat, 22 Jan 2022 18:04:14 GMT

I got stuck when writing unit tests

When I started writing unit tests, I faced a problem that you are most likely facing now. I've watched some unit test tutorials, but I got stuck and didn't know what to test when I put it into practice.

Should I test everything? Only the domain components? Should I test the CocoaPods I've been using? Should I test every single branch statement in my code? That feeling is terrible and almost made me give up.

After answering these questions, I caught myself in another tricky situation. My tests became too hard to maintain. But what was I doing wrong?

Key tips to know what to test

I didn't know what to test, and to solve that, I followed some simple tips. Check it out!

1. Follow design principles

As hard your test cases are, as badly designed your code is. This means that if your test is becoming hard to maintain, you have code smells in the subject under the test.

See some red flags warning you that your code should be redesigned.

Massive test setup and teardown
Big test methods
Big test case classes
Flaky tests

In this case, we need to check our code and refactor it due to applying some design principles. I recommend you study more about Design Patterns, Software Design Principles, and SOLID. However, to save your time, I strongly recommend you to explore the Dependency Injection and after Dependency Inversion Principle.

Dependency Inversion is the key to testability. When you apply it in your project, your code becomes more testable and enables us to use Test Doubles to pretend some system behaviors to achieve the real pure unit test.

The other design patterns also will be conducive, but you had better master the Dependency Injection and Inversion as soon as possible.

2. Test over the public API

A good practice that we follow is to control the class access through the private, internal, public modifiers. And this makes our test hard at a glance.

We should test our classes from the point of view of its consumers. Therefore, we need to test over the class’ public API.

We don't need to let all the class property and method public in favor of testability. This will bring us some design problems and some unexpected behavior. After all, we need to protect ourselves from ourselves. So, focus on testing the public API, which the class consumers actually use.

But what about my private API?

We will eventually test them implicitly by testing the public API. We need to configure the appropriate inputs to execute the private methods. When some private API becomes too hard to execute, it may indicate that your class has too much responsibility. It's time to refactor.

3. Test the behavior, not the structure

As beginners, we tend to look for each if-else, switch, guard, and design all tests to cover these branches. Well, that's a good strategy, but it's not my favorite.

Testing by looking at code structure leaves our test cases referring to code structure. As a result, always when our code suffers refactoring, the test will also have to be refactored. Our tests become rigid and hard to maintain.

I prefer to test the app's behavior, the use-cases, the features. In this case, the tests will only need to be changed if the behavior of the app changes. Otherwise, we can freely refactor our code, and the tests will continue to work. That's one of the main benefits of the unit tests: Make the software soft and easy to change.

Testing the behavior also implies that we won't need a test class for every single production class in our app, because we can implicitly test, through integration, more than one class.

4. Don't test third party code

Finally, I would say that we don't need to test third-party code. I always assume it is already tested. For example, I don't need to write tests to make sure Decodable works because I assume Apple has already done that. Same idea for an open-source code like Alamofire. It's not a rule if you feel safer writing tests for third-party code, no problem! In general, we can assume that third parties have already tested these codes.

Bonus

If after all these tips you are still feeling stuck, don't worry, step back and see this advices:

Test your code first

Testing code you haven't written can be tricky. It will become progressively easier:

I strongly suggest that you start by testing new classes that you are creating. It is much easier to add tests to something that is being created from scratch.
The next step is to add tests to the code you wrote a while ago.
Then write tests for bug fixes.
Here you start to have contact with code that is not yours.
Finally, you will be adding tests to the code you are working on, whether you wrote it or not.

I did it this way and I highly recommend it. It is much easier to first learn how to test in our code. Once we've learned, it's just a matter of moving on to other people's codes.

Lack of Requirement Analysis

Sometimes we got stuck because we don't fully understand the feature we are implementing. Step back and write down all the requirements for that feature. Do it with the Product Manager, Team Manager, Designer, and your pairs. It's part of the project planning and I don't recommend writing any line of code before you fully understand the feature.

Collect the happy path and all the possible error courses that the feature can run. After all, start implementing the feature.

Routine

Mastering unit testing demands practice and consistency. Don't be overly depressed about it, even if it is hard for you. Just keep trying, slowly, step-by-step, every day, and unit testing will become as natural as breathing for you.

Conclusion

To wrap it up, it's normal to get stuck when writing unit tests. It doesn't mean we don't know how to write unit tests but indicates that we need more attention on what to test.

This is my second article and I hope it helps you. Next posts I will start writing some Swift testing tips. Stay tuned! See ya!

Start Unit Testing right now

Will Policiano — Fri, 14 Jan 2022 22:53:21 GMT

Most likely, you've heard about unit testing and know what it is. I found unit tests out in 2011, but I actually used them just in 2018.

Writing unit tests has brought many benefits, both for the apps I develop and my career, but why did it take me so long to put this into practice?

In this post, I will present the barriers that developers often face that make them delay or even give up on the idea of writing unit tests.

So follow the tips until the end. I'm sure you'll want to write your first unit test today.

What is a Unit Test?

Unit Tests are low-level automated tests that focus on ensuring the correct functionality of small parts of the system. We can call these pieces unit, hence the name Unit Test. Test the unit, not the whole.

What we might disagree about is what is really a unit is. A unit can be anything from a function/method to a complete module. This definition will vary according to the context of the system, the developers, the team, and so on. However, I have noticed a consensus among iOS developers, who consider the public methods as a unit.

To understand better, let's take a look at the famous pyramid of test types:

This pyramid is divided into three types of tests. I can detail each type better in a future post, but the thing is that unit tests should be in greater volume in our project, as they are more isolated (and therefore easier to implement) and are very fast since we need to run them hundreds of times a day.

Therefore, we may agree that unit tests are the least expensive and bring the most benefits. Let's see why.

Why should I write automated tests?

I have asked myself this question several times. "I'm a developer, and QA is not my responsibility", I said.

We might not be responsible for the quality or the product's success, but I firmly believe that we are accountable for the quality of our work.

So as a professional developer, yes, I am responsible for ensuring the quality of the code I write. Besides, it's not just about professionalism. It's also about having a peaceful night's sleep, confidence in our excellent work and keeping yourself motivated.

There are numerous benefits to writing unit tests. Let's start with the programmer's benefits:

Get proud of your work: You will be able to finish the workday peacefully, as it is unlikely that your code has bugs.
Confidence when leading with legacy code: Change legacy code freely without being afraid of breaking something because if you do, the tests will let you know before you ship the app.
Refactoring: Code that has tests is future-ready. We can freely refactor using new technologies because the tests will ensure that the app's behaviour will keep working as expected.
Auto-Documentation: When we write tests, we are also documenting, which increases our requirements analysis skills. It's incredible how we discover several gaps in the app's functionality when writing the tests.
Avoid bug regression: Say goodbye to "I thought that I already fixed that".
Faster test suites: Decreases the need to run UI tests, which are much more expensive.

Your manager/client/company gets beneficiated as well. The main thing is the possibility of implementing a CI (Continuous Integration) and CD (Continuous Delivery), which enables all the following benefits:

Continuous Delivery: As the code is always stable and tested, the manager doesn't have to wait weeks or months to release an app version. Much more confidence when shipping their apps.
Continuous feature feedback: The consumer can build from the last main branch commit and try it on. They can do this several times a day and send you feedbacks/bug reports frequently.
Lower incidence of bugs: Bugs can be caught earlier during the development and can be fixed real quick.
Lower cost in general: A good quality project doesn't require a developer army. The manager won't need many QA people, and they won't need to spend much of their own time testing the app either. Also, fewer bugs mean satisfied users.
Trust in the relationship of developers and stakeholders: The team gets more motivated and honest. There's nothing worse than a dissatisfied manager with an app full of bugs and frustrated developers in the same team.

Note that this is not just about good code. Writing unit tests expands the company's matter.

I don't have time

I was working in a software house when I started studying unit testing. There, estimates and deadlines are sacred. Also, as a beginner developer and didn't have a flair for negotiating extra time to add unit tests to the project.

The point is: Do not negotiate. Just do it.

Once I understood this, I started writing my tests.

Your boss and your client don't care if the product has unit tests or not. They want to see the app working promptly. If you ask them to choose between Speed and Quality, they will undoubtedly select both. However, we know there is no way to conciliate speed and quality. We need to balance them. It's tricky because quality brings speed in the mid-long term.

We don't negotiate because they don't understand, and they actually don't need to. The developer is you. They choose what to do, and you decide how to do it. You are the specialist.

Of course, we can't just blow our estimates up without a good reason. If you're a beginner like I was, start slowly. Allocate an hour or two per week to writing tests. Don't worry about covering everything. With practice, writing tests becomes natural, and you will write tests faster and faster.

Once you've kicked things off, it's also essential that you gather the results of having written the tests and present them to stakeholders. So they may look with a different perspective and start to institutionalize this practice in the company.

Simple. Just get started without necessarily asking for permission. This risk is worth it if you want to become a first-class developer.

Code coverage obsession

Once we start writing unit tests, we will become obsessed with the famous Code Coverage. Code coverage is a good metric to understand how much tested code we have in the project.

Basically, it's a percentage of code lines executed during unit tests.

At first, we were obsessed with increasing this number, as it is one of the few quality metrics related to unit tests. This obsession becomes frustrating to us, especially in big projects. As big as the project is as hard to increase the coverage, and we will often see this number decreasing.

Note that this percentage doesn't prove much. Executing a given piece of code does not guarantee that it behaves correctly. Do you agree?

Finally, always try to cover all the use cases/behaviour of the project and the ~100% coverage will come as a reward for it.

Conclusion

In this post, I wanted to briefly introduce unit tests and share my experiences to convince you to write tests as soon as possible. For this post not to get too long, I decided to leave the hands-on for another post.

I hope this article has been helpful for you, and if you want to delve deeper into this topic, I'll be making regular posts on more advanced testing topics. If you want to learn how to write unit tests, check out this excellent article. See you!