TDD changed my relationship with Software Testing

Clarice Abreu
Mar 29 · 5 min read

I started learning programming in high school and I immediately fell in love with it. I loved to solve programming problems and challenge myself to improve my solutions. Then I enrolled in a Computer Science related Bachelor’s degree and got my first internship at a startup as a Software Engineer. With academic and professional experience I started consolidating my programming knowledge and improving my skills. Back then my programming process was more or less like this:

First Programming Process Diagram
First Programming Process

This process can also be represented in a habit loop:

Diagram of the Process Represented in Habit Loop
Diagram of the Process Represented in Habit Loop
Process Represented in Habit Loop

I haven't learned to write automated tests such as unit or integration tests in the university. Besides that, in my first two professional experiences I also didn’t write any automated test. Therefore, I got pretty used to the process in which I was rewarded with the pleasure of knowing the problem was solved after executing my program and checking that it was working through manual tests.

Then, I became a QuintoAndar employee which is a company that has a strong software testing culture. At QuintoAndar the engineers should always write tests for their code. So I had to learn not just to write automated tests but also how to add them to my programming process. My first attempt to change my coding routine looked like that:

Second Programming Process Diagram
Second Programming Process

The new version of the process was much longer, and I often spent much more time trying to make the tests work than coding the implementation. This was happening because many times I didn't write a code that was easy to test, therefore I had to rewrite it or create complex testing structures/algorithms.

However, the biggest problem was not the size of the process, but the feeling of frustration I felt when I was testing. This was happening for two main reasons:

  1. Since I was only writing the automated tests after asserting the implementation code was working through manual tests, I felt I needed to write them just to prove that.
  2. I was really used to my previous habit loop, so once I fished the manual tests I was expecting the reward of knowing the code was ready. Instead, I still needed to write all the unit/integration tests and make them work.

Now I understand the cause of the problem. I used to though that “coding the implementation” and “testing the code” were two separate processes. And I would only start the second after finishing the first.

Then, I knew I had to change my relationship with software testing in order to stop getting frustrated every time I had to write automated tests. That's when I started studying more about the subject and came across TDD (Test-driven Development). I already knew TDD existed, but I didn’t know much about the approach. When I started to apply it, not only I improved my productivity, but I also started developing higher quality software

TDD can be applied in different ways, but the main idea is that the automated tests are written the implementation code. They should reflect the requirements of the problem you are trying to solve. Therefore, every rule or expected behavior should be tested. Here are 3 simple steps to accomplish that with TDD:

  1. First, write unit/integration tests or any other kind of functional test script that will assert that your code will work as expected based on the requirements. It is a good practice to run all the tests before writing the implementation to make sure they all fail (this prevents false positives). — This is known as the Red phase;
  2. Write the implementation code to pass the tests. — This is known as the Green phase.
  3. If necessary, refactor the implementation code to improve it without changing its behavior. — This is known as the Refactor phase
TDD cycle
TDD cycle — Image by Dmitry Chekalin on Codica

TDD has many benefits, but, for me, the best one is that you have to think about how you are going to implement the code before doing it. Planning all the classes, methods and data structures that will be used is essential, since writing the tests for them comes before the actual implementation.

That’s what makes all the difference. When planning, it is necessary to think about how you are going to code and to test simultaneously. Therefore, coding the implementation and testing it start to be two things that evolve together and are entirely related. They stop being two separate processes that are going to be done one after another.

Finally, my current programming process is like this:

Current Programming Process Diagram
Current Programming Process Diagram

Yes, this process is still longer than the first one, but now I develop much better software and I can do it even faster! Before I started planning my implementation, I often started coding and suddenly realized that my code was not going to work, so I had to change my approach and rewrite the code. Also, I often caught bugs during the manual tests which were done only after the whole implementation was ready. Now, instead of that, I can execute the automated tests at any time of the development, so it is possible to catch the bugs sooner and fix them faster.

The frustration I was experiencing was gone because the automated tests started being to be more confident that my code was meeting the requirements even before executing it.

If you have never applied TDD give it a try, it may also change your relationship with software testing!

Thanks for reading! I’m always open to receive feedback, recommendations, or questions, feel free to contact me!!


QuintoAndar Tech Blog

A peek into how we get things done

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store