A few words about TDD

What TDD is

TDD or Test-Driven Development is a software writing technique that overturns the approach to code development by 180 degrees. I think it is intuitive for us that in order to be able to test something, you must first create it, and then test it. The TDD approach is quite the opposite. We start creating functionality by writing a test, and only then implementing the actual code that will be tested.

There is an established pattern that helps very well to understand how to approach TDD. This scheme is actually a three-phase cycle that is repeated iteratively until the production code meets the required business logic. Here they are:

RED phase - creating a test

This is the phase from which we start the TDD cycle. Its purpose is to write a test that will not pass during testing, and it should always be so at the beginning. We write one small test functionality and then we go to the next phase.

Green phase - creating the actual code

In this phase, implement a MINIMUM amount of production code that will allow you to pass the test. Only when the test turns green, we go to the next phase.

Code Refactoring Phase

This phase consists in bringing the created code, both test and production, to the most "elegant" form. It is important not to neglect this phase because it largely allows you to write an application that is readable for other programmers, and also well-optimized.

After the end of the cycle, we return to the red phase, i.e. writing another small functionality of the test, making the test turn red again. Then we move on to the next phases, until the business logic is correctly implemented and the tests go green.

Why using TDD

Since we already know what the procedure for using the TDD method is, we should consider why use this approach at all. Any writing tests means that you have to write a lot more code, and it does not matter whether you write tests after or before the implementation of the functionality. Nevertheless, the time spent pays off with a vengeance later.

The TDD method allows you to create code that will be easily testable, because we start the test and follow it to its passage. The initial determination of the purpose that the production code is to fulfill makes it easier to write code that will perform well under various boundary conditions, such as passing null values to functions and methods.

Writing a lot of tests allows you to easily catch various bugs that may be difficult to track later. There may be times when you need to make changes to existing code. If you write a lot of tests, you may find that you can save hours of trouble searching for a bug later.

However, in my opinion, the most important advantage of using TDD is the fact that the programmer is forced to write tests, which often recede into the background after writing a working code. TDD enforces a certain rigor of procedure and organizes work. In addition, each passing the test green is a kind of reward and certainly motivates you to continue working in the long run.

A few rules on how to write correctly in TDD

So that all our work devoted to writing tests is not wasted, it is worth applying a few basic rules:

Write unit tests

Unit tests are characterized by the fact that they test a small fragment of the code, and thus perfectly fit the idea of dividing individual implemented functionalities into smaller steps and iteratively adding successive bricks to the code

Apply the given-when-then principle

It is worth following this rule because it organizes the code very well and allows you to easily and quickly understand the functionality that a given test checks.

@Test
void testSummingTwoNumbers() {
 
    //given
    Calculator calculator = spy(Calculator.class);
    given(calculator .getFirstValue()).willReturn(2);
    given(calculator .getSecondValue()).willReturn(3);
 
    //when
    int result = calculator.sumNumbers();
 
    //then
    then(calculator ).should().getFirstValue();
    then(calculator ).should().getSecondValue();
    assertThat(result, equalTo(5));
}

I will cover the above code in more detail in the section on spy, but it clearly shows 3 sections organizing the test.

Call tests intuitively

It is important that the name of the test clearly defines what the test is checking. Don't be afraid to use longer names if necessary. When a test later turns red, it will be easy for you to find the reason why the test failed.

Test after refactoring

It should be remembered that the tests should also be run after the code is refactored. Sometimes, a seemingly small change can inadvertently lead to bugs that will change how your code works.

Have moderation

Especially in the initial fascination with the TDD method, you can overdo the code coverage with tests. Let's not test obvious things such as setters and getters. Remember that the execution of the test usually takes little time, but if we write these tests several hundred or several thousand, running them can be really time-consuming.

Separate the test code from the production code

Remember that the test code should be in a special place for this purpose. Usually, the IDE and the frameworks we work in will make sure that the production code is in the src directory, and the test code is in a separate test directory.

Isolate the tests from the working environment

It is important that the tests are performed in isolation from the environment in which we work. The point is not to reference local files, databases. This is where mock, stub or spy objects come in handy, which you can read about in the following paragraphs.

Mock, Stub, Spy

The title terms refer to the objects that we create in order to test the operation of the methods in the test. They can be called a kind of guinea pigs. What exactly are these objects.

Stub

This is the most primitive way to create an object on which to test. This object is built on the basis of a stub class that is intended to simulate the operation of a real class. It is used, for example, when we do not have access to the real classes, but we know its functioning principle, or when the methods we test require data operation, and as I mentioned earlier, we should isolate the tests from the code work environment.

The disadvantage of using such a solution is that in the case of expanding the class we are testing on, we must also expand the stub class as needed.

mock

Mock is an object type that is automatically generated based on the class we want to test. Usually, to use mocks, additional libraries are required, such as Mockito for Java. The method of creating an object is very simple, and in the case of Mockito it may look like this:

MySampleClass mySampleClass= mock(mySampleClass.class);

This one line of code causes a new object to be created, the fields of which are filled with simple data, such as 0 values for integer fields. The advantage of this solution is that we do not have to create separate classes for testing purposes. mockujemy is automatically taken into account when creating a mock. In addition, libraries such as Mockito give us many tools to check what parameters were used when calling a given method or count, for example, the number of times a given method was called.

Spy

It is a kind of combination of mock and stuba. Its main advantage is that it gives the programmer flexibility because it is created on the basis of the class that we simulate, but we can impose, for example, what values each method should return and use them later to test another method.

@Test
void testSummingTwoNumbers() {
 
    //given
    Calculator calculator = spy(Calculator.class);
    given(calculator .getFirstValue()).willReturn(2);
    given(calculator .getSecondValue()).willReturn(3);
 
    //when
    int result = calculator.sumNumbers();
 
    //then
    then(calculator ).should().getFirstValue();
    then(calculator ).should().getSecondValue();
    assertThat(result, equalTo(5));
}

In the above code, we simulated returning values from getters, and then we used the obtained values to test the code that sums two numbers in the sumNumbers () method:

int sumNumbers(){
    return getFirstValue() + getSecondValue();
}

Each of the methods shown has its advantages and disadvantages, but they provide a wide range of possibilities and are a real improvement in writing application tests.