Introduction to TDD

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


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 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.

Replacing Conditional Getters With Functional Programming in Java

1. Introduction

In this small article, we will have a look at how to efficiently write a code that runs a getter (or any other method) based on some input using functional programming.

2. Problem

Instead of explaining it in words, let me show you the code directly:

private int normalMethod(MyPojo pojo, Actions action) {
    if (action == Actions.ACTION1) {
        return pojo.getActionOne();
    } else if (action == Actions.ACTION2) {
        return pojo.getActionTwo();
    } else if (action == Actions.ACTION3) {
        return pojo.getActionThree();
    } else {
        return pojo.getActionFour();

As we can see, we are calling the appropriate getter based on the Action that we get in the input. This seems to be pretty decent at the moment, but as and when there are new actions/getters, we need to modify the code and the chain can grow longer.

3. Solution

One good solution to this is to make use of functional programming in Java. For this, we need to create a mapping of the Actions to method references:

public static final Map<Actions, Function<MyPojo, Integer>> GETTERS_MAP = new HashMap<>();
GETTERS_MAP.put(Actions.ACTION1, MyPojo::getActionOne);
GETTERS_MAP.put(Actions.ACTION2, MyPojo::getActionTwo);
GETTERS_MAP.put(Actions.ACTION3, MyPojo::getActionThree);
GETTERS_MAP.put(Actions.ACTION4, MyPojo::getActionFour);

As we can see, we have mapped every Action to the corresponding getters. Once this is done, our long if-else chain now reduces to only a couple of lines:

private Integer functionalMethod(MyPojo pojo, Actions action) {
    Function<MyPojo, Integer> getter = MyPojo.GETTERS_MAP.get(action);
    return getter.apply(pojo);

And that’s it. Even if we need to add another Actions/getters, we just need to add an entry in the Map. The method above doesn’t need to be modified.

4. Conclusion

We have observed that functional programming opens new doors of creativity. Please find the full source code of this article on GitHub.

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


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


Make sure you have modified your 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


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 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


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


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”

How do I version my API?

Almost every enterprise application needs integration with one or more external systems. Different systems talk with each other using a set of well-defined APIs. However, as the system grow, you might be adding/removing/modifying the existing functionality. In this case, you need to be careful so that you don’t break the other system that might be using your APIs.

In order to tell the outside world that something has changed, we release different versions of the API. But how do you manage the versioning? Are your versions meaningful to the users? Do they convey an important message?

Semantic Versioning

Personally, I feel that you should be using Semantic Versioning (SemVer in short) if possible. Semantic versioning has been developed based on the existing notions of API versioning and addresses many problems efficiently. Below are some important points that define Semantic Versioning.

  1. The version number follows the convention MAJOR.MINOR.PATCH (example 1.3.2)
  2. Do not add preceding zeros to the versions. For example, doing 01.03.10 is not correct. This could easily lead to confusion.
  3. During initial development, keep the MAJOR version as 0. For example 0.1.1
  4. Once the first version is released, make it as 1.0.0
  5. Keep all the numbers nonnegative.
  6. The PATCH version must be incremented only if you make backward compatible bug fixes.
  7. The MINOR version must be incremented if you make backward compatible changes. This might also include introducing new features.
  8. When you increment the MINOR version, reset the PATCH version to 0.
  9. The MAJOR version must be incremented when you make backward incompatible changes. Reset MINOR and PATCH version when you do so.
  10. You can have additional labels for pre-release and build metadata are as extensions to the MAJOR.MINOR.PATCH format.