Introduction to TDD

How it is done is as important as having it done

A basic "application"

A person is defined by its NAME
- In uppercase
- Without digits

Testing is doubting ?

Objection !

Any piece of code is guilty unless proven otherwise !

The tools

JUnit

JUnit with coverage

Code Coverage

The tools

AssertJ

@Test
public void shouldGetFeatureFromService() {
    FeaturesService service = mock(FeaturesService.class);
    RoleExpressionParser parser = mock(RoleExpressionParser.class);
    Feature defaultFeature = defaultFeature();
    FeaturesController controller = 
      new FeaturesController(service, parser);

    when(service.getFeature(anyString())).thenReturn(defaultFeature);

    ResponseEntity<Feature> result = controller.getFeature("hello");

    verify(service).getFeature(eq("hello"));
    assertThat(result.getStatusCode()).isEqualTo(HttpStatus.OK);
    assertThat(result.getBody())
      .isEqualToComparingFieldByField(defaultFeature);
}

TDD Cycle

Think & Write a new Test case
Red - Assert new Test fails
Green - Write the code to make new Test pass
Green - Assert all Tests pass
Refactor / Clean code
Repeat

In test-driven development, each new feature begins with writing a test. This is a differentiating feature of TDD versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code.
1. This validates that the test harness is working correctly, shows that the new test does not pass without requiring new code because the required behavior already exists, and it rules out the possibility that the new test is flawed and will always pass.
2. The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may, for example, pass the test in an inelegant way. That is acceptable because it will be improved and done in Step 5.
3. If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.
4. The growing code base must be cleaned up regularly during test-driven development. Duplication must be removed. As features are added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve readability and maintainability.
5. Starting with another new test, the cycle is then repeated to push forward the functionality The size of the steps should always be small, with as few as 1 to 10 edits between each test run

TDD Cycle

TDD cycle

Live Coding

Let's try it !

A person is defined by its NAME
- In uppercase
- Without digits

Practices to avoid

Dependencies between test cases (order, state, ...)
Testing implementation details (test only what is exposed)
Testing other components (other classes, libraries, ...)
Slow running tests

To go further

A.T.D.D. / B.D.D
Integration tests
E2E Tests
Performance tests
- Ramp-up
- Peaks
- Limits
- ...

To go further

Tests pyramid

Unit Tests: Unit tests are very low level, close to the source of your application. They consist in testing individual methods and functions of the classes. Unit tests are in general quite cheap to automate and can be run very quickly by a continuous integration server.
Social Tests: Social tests are low level. They consist in testing how different classes of your application communicate with their neighbouring classes. Usually neigbours are mocked to simulate they behaviour as required. Like Unit Tests they are cheap to automate.
Integration Tests: Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.
End to End: End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc...

It's your turn

Let's code in T.D.D. !

Thank you !

Copyright © 2020-2025 Gwendoline FICHANT

Introduction to TDD. How it is done is as important as having it done.

Slides
Close

Introduction to TDD
A basic "application"
Testing is doubting ?
The tools
The tools
TDD Cycle
TDD Cycle
Live Coding
Practices to avoid
To go further
To go further
It's your turn
Thank you !