SIX REASONS I USE Test Driven Development (And why you should use it as well)

What is TDD?

Test-Driven Development, or TDD is a methodology in which you create your program by enumerating the test cases that it needs to pass, and then you code the necessary code in order for the tests to pass.

Normally we use automated tests frameworks like JUnit.

You can get started with this methodology very quickly.

1. Write a failing test
2. Write a program that will pass all your tests
3. Once all your tests pass, refactor your code and make sure that you didn’t break any test

This cycle is usually called: RED, GREEN, REFACTOR

There are many things that can be explained about TDD, but it all comes down to that? simple cycle.

So, why do I like it so much?

1| It’s the best way for me to understand what my program must do

Applications, business logic, error handling, etc., can get extremely complex if left unchecked. Being able to understand all possible scenarios, and different flows that the program can actually take can be a pain.

To me, the best way to understand what an application has to do is simply writing all the different possible scenarios as test cases.

I got this Idea from a book called “Bridging the communication gap” by Gojko Adzic. His idea is that the best way to extract the knowledge of a Business or Domain from a Subject Matter Expert is by using examples:

• What happens if the user clicks on the submit button, but? the form is not complete
• What happens if the 3rd column of the CSV file is empty?
• How many payment methods do we show to the user if they haven’t created an account?

Examples are the best way to bring something abstract, such as a business process, to a way more concrete level.

We use examples to communicate ideas all the time, because they are extremely helpful. I just used example questions just 30 seconds ago.

I use this methodology even when I speak with product owners and business analysts. I get together with them and basically start writing test cases as examples. During these chats, we come up with concepts or abstractions that might represent different scenarios. It’s really helpful to extract ideas from the SME/Product Owner/Client’s mind.

These examples can then become test cases that we can automate and run over and over against our code.

2 | It forces you to test your code

This can be rather obvious, but because you are using a methodology that is focused on making tests pass, it makes sure that you absolutely test your code.

Honestly, I’ve never liked code coverage tools. I’ve seen terrible tests that don’t actually test anything, written for the sake of reaching some randomly assigned percentage of test coverage.

And sometimes, because we use frameworks that have a lot of boilerplate, we are forced to write tests for this boilerplate, in order to make our test coverage tool happy.

That’s not only a waste of time, but also gives TDD a bad reputation.

Real TDD doesn’t focus that much on code coverage. It focuses on test case development. You actively think of all the different cases for the inputs of your tests and all the different outputs and you write tests for this.

3 | Simpler design usually comes out of it

Since our focus is in making our test cases pass, our design tends to be simpler. Once our tests are all green, we can refactor our code as much as we want.

Refactoring is the key part in improving the design of our code when we are doing TDD. If you don’t know what refactoring is, then there are a couple of very interesting books you can read, like “Refactoring” by Martin Fowler or “Working effectively with legacy code” by Michael Feathers.

In short, refactoring is applying transformations to your code that will not add any new behavior or logic to it. You don’t add any new features by doing refactoring. You only make your code prettier, easier to understand and maintain. The reality is that most of the time, we don’t write code only for ourselves, but we do it for others. That’s why we want to write code that is easy for others to read and understand what is happening.

TDD allows you to write simple code and it gives you a safe mechanism for you to refactor once your test passes.

4 | It goes really well with Functional Programming

If you have been following me or this channel for a while, you know I love functional programming. That’s why I have a series on Functional Programming and I use Kafka Streams so much. TDD is excellent when paired with Functional Programming. In this programming style, our functions tend to be extremely easy to test, because we have some assurances:

• For a given input, we will always have the same output. So test cases for this type of function are really easy to test.
• Data is immutable, so when we do assertions or verifications, we can be sure that the values of our variables haven’t changed.
• Side-effects, which are harder to test, are isolated on the edges of our system so that our main logic consists of pure functions. And we can use techniques like mock objects for testing side effects.

5 | Great for pair programming

Doing pair programming is one of the best things that we get to do as developers. It’s such an enriching activity. You can learn from your buddy and your buddy can learn from you. I use this methodology a lot in my teams. And I think it’s a great way to share knowledge to a new member of the team as well.

With TDD, we benefit a lot from pair programming, because it’s not just one person, but two who can think about the test cases that need to be passed.

6 | Out of the box documentation

Once you have all your tests written, they become documentation out of the box. If someone needs to learn what your class does, they can take a look at how it behaves under particular scenarios by looking at the different tests. That’s why it is so important that we take good care of the way we write our tests. Having well written, clear, expressive tests is a great way for people to learn about what our code does.

If you enjoyed this article, I encourage you to visit my youtube channel Programming With Mati.

You can watch my video about TDD here: Start using Test-Driven Development NOW! 6 reasons why I use it!