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!