Getting started with TDD
During my years in IT, only after a time I heard about the automated tests and TDD (Test Driven Development). In this article I’ll explain how to create UT (unit tests) using TDD.
In my opinion is to define the program scope, ie, if you are using TDD (Test Driven Development), the famous Red, Green, and Refactor. This works well on a green field class, or system, as will be shown in this article.
Put it in your mind “Make it work. Make it right. Make it fast.” (Uncle Bob). So few people in the world can see the big picture, then do small steps, evaluate and make it better and fast.
The change of production code could have side effects, and as soon as we can test, avoid errors and be sure the code is right, is great for the team/company.
However when you’re working on a legacy system, frequently we’ve the UT, the class etc, but this is not an excuse to code a great UT.
The SOLID principle more specifically to S (Single responsibility principle) and isolate the D (Dependency inversion principle) are part of a good design and the UT + TDD help us on it. But remember, having 100% of tests means your system is failure proof and meets the business requirements.
2. Hands on 💻
For this hands on, you will need to create a project based on Gradle, since we need to add the dependency to JUnit 5 framework. You can do it by adding the library manually, if you want.
2.1. Recap the TDD
The steps to create a project and write a JUnit 5 are:
Open your IntelliJ IDEA, and choose the option File → New → Project, and select the Gradle option, on the left.
Fill the required fields and continue
Wait some time in order for the project to be rendered.
2.2.1. Project dependencies
Voilà 🙌, we have an empty project.
The domain will be a service that gets movies recommendations by user. Since Netflix is widely known, our service will be created using the name NetflixService and will be responsible to get recommendations given a user.
I’ll not bring up this topic in this article, but if we want, we can use Gherkin to write this use case.
Scenario: Get movie recommendations by user
Given an user
When has recommendations
Then return a list of movies
As expected, the first test failed, since the production code is not implemented, and has a null return.
Once the test fails, it’s time to fix it. Since the test expects a not null value, we can change the null return from the service to an empty list, ie, Collections.emptyList().
The next step is to call the Recommendation service, then let’s add the class and make the call.
On the screenshot above we declare the service, but not inject the dependency, this give to us a NullPointException 😉
To simulate the Recommendation service, let’s use another library, the mockito, is not the drink but leave your happy at the same way
Mockito helps us to tackle the class dependency and lets us just focus on what really matters, our method scope.
When the Recommendation is called, we’re mocking the result and give some Matrix movies as recommendation, and assert that we’re receiving 3 elements of NetflixService.
Since we don’t have any refactoring at this moment, the test is done and the production code does exactly what it needs based on test scope.
Below we can see the services. In the class RecommendationService we’re throwing an unchecked exception, since this method is not ready.
Tests help us a lot daily and having automated tests much more. When possible use TDD or at least create the UT upfront, this will save time and money, since the scope is more accurate.
Is not easy to be familiar with TDD or even automated tests when you’re starting on the language or career, but it is a path to be thrilled.
GitHub - luizgustavocosta/automated-tests
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
Building Java & JVM projects
Gradle uses a convention-over-configuration approach to building JVM-based projects that borrows several conventions…
Create a new project | IntelliJ IDEA
This section describes the functionality available out of the box. If you are using a framework plugin, refer to the…
SOLID: The First 5 Principles of Object Oriented Design | DigitalOcean
SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle…
Clean Coder Blog
When you first learn Test Driven Development, it sounds simple and easy. If you learned it in 1999, like I did, the…