Introduction to TDD

When you realize the true power of tests for the first time

Introduction

TDD or Test Driven Development is a development methodology that completely changes the way we develop our code. Although this has drawn some criticism, its still getting more and more popular and TTD is considered as an important skill in many job listings.

TDD forces the developers to write the tests first, even before writing the production code. Wierd, you say. Not really, actually.

Why Tests First?

Why not? I mean, don’t treat your tests as second-class citizens of your project. They are as important as the production code, if not more.

Tests are your weapon, the stronger they are, the more powerful you become. They enable us to understand the code, quickly modify it, and bring down the maintenance cost. Don’t believe me? Take my word for it.

What is the best way to understand any new library or a framework? Even we have well-written docs in good English, what we, as developers, always look for is the “code examples“. This is because we prefer well-written code over well-written sentences.

Our tests are code examples of our production code. The tests tell other developers how to use this code and what scenarios should they consider. This brings down the learning curve.

Test Driven Development

How to do TDD?

In TDD, we start with tests first. Since we are starting with tests, it’s obvious that the test will fail. Then we write the production code just enough to pass the failing test. Once done, write another failing test and the process repeats. This way, we are writing code in very short test/development cycles.

It makes sure that all of our production code is covered with the unit tests, which is a good thing.

Following this process forces the developers to have clear API contracts. They are forced to think how the methods are gonna be used by the outside world. When I say API, I mean any public methods that we expose from our classes.

It automatically makes our code easily testable.

Many would argue against this practice saying that it requires more time, but actually, it doesn’t. Whenever we feel like making any changes to the code, we will be able to do so effortlessly, knowing that the tests have our back. This will save a lot of time. Always remember, the code is going to change, today or tomorrow. And when the time comes, you will bless yourself or the original developer for writing such concrete tests.

Fragile Tests

Ever been in a situation where you modify a small bit of code that results in multiple test failures and you find yourself modifying tiny pieces of code in all the failing tests just to find some other tests failing?

Congratulations, you have discovered fragile tests. Many people find themselves stuck in the loop of fragile tests while following the TDD. But think again, is it really the problem of TDD? Or an advantage of TDD?

Having fragile tests that break every now and then is not the problem with TDD, in fact, its the problem with the tests themselves. TDD or not, bad tests are bad tests. They will keep haunting the developers till they exist.

So how does TDD help in writing effective tests? If you find yourself modifying every test while writing code, it is a signal that our tests need refactoring. It’s better to refactor 10 tests than refactoring 50 tests.

BUT…

But my teammates are not interested in TDD. But my manager doesn’t approve of TDD. But my architect thinks TDD we are not prepared for TDD. But, but, but…

This will never end. Understand that explaining the benefits to the team is our responsibility. We need to make them understand that this is the correct way. Even then if no one listens to you, we can still follow the practice on our own.

It is up to the individual whether to follow TDD. Our managers need not worry about the methodology if your performance is good. It’s an individual’s practice.

The next article/video shows you how to actually write code using TDD methodology. See it in action.

If you are just starting with Java or are confused with terms like Java SE and Core Java, head on to this article to simplify things.

Creating a strong foundation for a new project using Spring Boot – Part 4

Contents

This post is divided into four parts.

  1. Getting Ready
  2. Unit testing
  3. Integration testing
  4. Launching the app

Launching the app

At this point, our application is complete. You can launch the app by executing the following command.

[code language=”plain”]

gradlew bootRun

[/code]

Make sure you have modified your application.properties according to your DB and that your DB is up and running.

Try our some GET/POST requests. You can use CURL or a GUI based chrome extension Postman. There are similar tools available for other platforms. Make sure to query your DB to check the modifications.

Adding the ability to run anywhere

Making your application flexible enough to be able to run on anywhere could be very useful. Particularly when you have to demonstrate. Continue reading “Creating a strong foundation for a new project using Spring Boot – Part 4”

Creating a strong foundation for a new project using Spring Boot – Part 3

Contents

This post is divided into four parts.

  1. Getting Ready
  2. Unit testing
  3. Integration testing
  4. Launching the app

Integration tests

In integration tests, multiple layers communicate with each other and we test multiple layers of the system in a given test. It’s a good idea to keep your integration tests separate from unit tests. You will run unit tests more often, with every build for example. The integration tests might run with a nightly build.

Create two new source folders src/integrationTest/java and src/integrationTest/resources in your IDE. In eclipse, Right click on project>New>Source folder.

Create a new file application-integrationtest.properties in  src/integrationTest/resources. Continue reading “Creating a strong foundation for a new project using Spring Boot – Part 3”

Creating a strong foundation for a new project using Spring Boot – Part 2

Contents

This post is divided into four parts.

  1. Getting Ready
  2. Unit testing
  3. Integration testing
  4. Launching the app

Unit tests

The “spring-boot-starter-test” is automatically added when you create a new project. If you are familiar with Spring test, you might be aware of @SpringBootTest annotation. But that’s an overkill for a unit test. @SpringBootTest has the power to start an embedded container, which can be useful in integration tests, but more than required while testing the DAO layer. Since we are testing small “units” of the application of the application, we need to be focused on testing more specific “slices” (Controllers, Service layer, DAO layer). Luckily, it’s really easy to do this.

Let’s create our first test.

Testing the DAO layer

I know we have not written any DAO layer code in our application, still we can verify if the repositories are configured properly. Moreover, as the application grows, you might feel the need to have unit tests for the DAO layer. Starting early will help in this case. Continue reading “Creating a strong foundation for a new project using Spring Boot – Part 2”

Creating a strong foundation for a new project using Spring Boot – Part 1

Contents

This post is divided into four parts.

  1. Getting Ready
  2. Unit testing
  3. Integration testing
  4. Launching the app

Creating a strong foundation for any new project is critical for timely delivery as well as maintainability. Frameworks like Spring Boot and tools like Gradle are meant for rapid development. However, if not utilized correctly, these can become a bottleneck and hinder your pace of development.

Let us see how can we create a solid foundation of any new project that provides you high testability as well as portability. This post, by no means, claims to be a perfect example, however, it should provide you a good enough ground to play around.

Not a standard Spring MVC app

We are not going to discuss “How to create a Spring MVC app” here. In fact, the sample app that we will develop will have minimal functionality. Our main focus will be how to set up the project so that it can be developed quickly. We will talk about organizing unit tests, integration tests, while keeping the tests independent such that they can be run on any machine without having any dependency on the infrastructure. Continue reading “Creating a strong foundation for a new project using Spring Boot – Part 1”

Moving on to Assertj assertions – beginner examples

Assertj examples

This post describes the use of a relatively new but a fluent assertion library, Assertj.

1. Introduction

Assertj provides simple yet effective way to assert your tests. It provides a powerful mechanism to make your assertions compact and readable.

2. Dependencies

Add the following dependency to your project.

Gradle:

[code language=”plain”]
testCompile ‘org.assertj:assertj-core:3.5.2’
[/code]

Maven:

[code language=”xml”]
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<version>3.5.2</version>
</dependency>
[/code]

3. Getting ready for the examples

We will deal with some real examples in this tutorial. Hence, we need a project setup to work with. Please note that all the source code used in this tutorial can be found on github. Link is at the end of the post.

Continue reading “Moving on to Assertj assertions – beginner examples”