TDD IN JAVA

Can you actually write a test before writing a single line of implementation logic?

How do you know what method, class, or interface will contain the logic?

Sounds a bit odd…

That’s exactly how I felt when I first read about TDD.

But once I got the hang of it, I realised…

That’s the whole point!

It guides you through the design.

So don’t worry,

In this post, I’ll demonstrate each step with a simple example.

Example

Requirement: I want a function that prints ‘Hello World!’.

This piece of requirement is so small that it need not be broken down further.

Now let’s write a test to validate this behaviour.

So where should we start?

Start with an assert.

That’s the easiest, and best in my experience.

There are so many assert methods in the JUnit framework.

Which one should I use here?

Well, I almost always use assertThat.

assertThat(actual, matcher);

There are two parameters we need to pass into this method.

1. The first parameter is the ‘actual’ or the return value from the method under test.

   We don’t have a method yet!

   So, we got to think backwards here.

   Normally what happens is, there is a class with a method in it. When we want to call the method, we create an object of that class and call the method on that object.

           
        Example example = new Example();
   
        example.method();
   
   

   There’s neither a class nor a method in this case.

   Thinking backwards, I’ll start with the method. Looking at the requirement, we are going to test whether the method returns the string ‘Hello world!’.

   So, I’ll name this method getMessage(). We can always change these names later.

   Now we need an object to call this method on.

   To create an object, there has to be a Type (a Class or an Interface). The class hasn’t been created yet, but we sure can give it a name.

   I’ll start with the object and name it greeting.

   greeting.getMessage()

   So now the first parameter is all set, but we still got to create this object and initialize it to get this test compiling.

   Greeting greeting = new Greeting();

2. The second parameter is a matcher, which is an expression, built of org.hamcrest.Matchers, specifying allowed values.

   So the method I’m going to use here is is from hamcrest - org.hamcrest.CoreMatchers which returns the Matcher.

   The expected value is the String “Hello world!”, so I’ll pass it into the is() method.

If you want to learn more about using hamcrest matchers, check out my JUnit4 Tutorial.

Finally, the assert is ready.

assertThat(greeting.getMessage(), is("Hello world!"));

Here’s the failing test:

   public void test(){

      Greeting greeting = new Greeting();

      assertThat(greeting.getMessage(), is("Hello world!"));
   }

As a result of Writing the test, and getting it to compile, we have the skeleton of the implementation.

Here’s what we have so far:

public class Greeting {

  public Object getMessage() {
    // TODO Auto-generated method stub
    return null;
  }

}

The very minimum we have to do to pass the test is to return “Hello world!” instead of null.

Here’s the implementation

public class Greeting {

  public Object getMessage() {
    // TODO Auto-generated method stub
    return "Hello world!";
  }

}

It may look dodgy, ugly and you might be itching to do a little bit more here . But be patient, we only want to get the test passing at this stage. We will definitely refactor this in the next step.

Run the TEST!

Now that we have a passing test, it’s time for the next step.

This step is as important as the two above. Refactoring both implementation and test is crucial.

Why should you care about the tests?

You’ll see the answer later in the section Quality Matters.

Refactoring the Implementation

The existing implementation definitely needs some dusting and refactoring.

So I’m going to do the following:

1. Remove the auto-generated comment.
2. Change the return value from Object to String.
3. Extract the String “Hello world” into a field.
4. Initialize the field in the constructor - this step is optional, actually, it would be better off without this. But I have included this just so we see that refactoring the implementation may result in changes to the test as well.

Make sure to run the test after each change.

  public class Greeting {

    public Object getMessage() {
      // TODO Auto-generated method stub
      return "Hello world!";
    }

  }

  public class Greeting {

    private String message;

    public Greeting(String message) {
      this.message = message;
    }

    public String getMessage() {
      
      return message;
    }

  }

As a result of the above refactoring, the test has been changed as well.

  @Test
  public void test(){

    Greeting greeting = new Greeting();

    assertThat(greeting.getMessage(), is("Hello world!"));
  }

  @Test
  public void test(){

    Greeting greeting = new Greeting("Hello world!");

    assertThat(greeting.getMessage(), is("Hello world!"));
  }

Refactoring the Test

When it comes to refactoring TESTS, you got to turn your back on some of the BEST PRACTICES that you follow when you write production code. Because,

GOOD TEST CODE != GOOD PRODUCTION CODE

You got to break some rules here. So, don’t start refactoring your tests before you read these rules of thumb.

Looking at the rules above, you might think, is there anything left for refactoring in the unit test?

Well, in my experience there is always something/s that you can do to make it better.

1. Now for this Test, I can extract the local variable into a field, so that it can be used in other tests of the same class.

   You can go one step further and move the initialization of the field to a setUp method which would run before every test method. But I’m going to stop here for this example.

   Checkout my JUnit4 Tutorial, if you want to know how to use setUp and tearDown methods in JUnit4.

2. Then the next important thing is the name of the test.

   I’m following the naming convention introduced by Roy Osherove, which is excellent.

Naming convention for test methods

  public class GreetingTest {

    @Test
    public void test(){

      Greeting greeting = new Greeting("Hello world!");

      assertThat(greeting.getMessage(), is("Hello world!"));
    }
  }

  public class GreetingTest {

    private Greeting greeting;

    @Test
    public void getMessage_whenInitializedWithGreeting_returnsGreeting() {
      
      greeting = new Greeting("Hello world!");
      assertThat(greeting.getMessage(),
          is("Hello world!"));
    }

  }

HELLO WORLD IN TDD

It’s that simple. So what’s keeping you from practicing TDD? Let’s get started.

For the majority of us who are so used to writing the method or function first and writing the unit tests later or maybe skipping it altogether, it may feel like swimming upstream.

But like anything, a bit of practice will make it a lot easier and natural.

Following are a few things that motivated me and also planted the foundation of TDD in me.

• Test Driven Development: By Example” by Kent Beck - Reading this book, set my mind up for it and it really extracts the essence of test driven development.

• Writing great unit tests i.e. simple, understandable, and maintainable unit tests.

• TDD Kata - Small practice exercises that help you master it.

Yes, the quality of unit tests does matter as much as the quality of production code.

Some qualities of a GOOD unit test

• Each unit test should be able to run independent of other tests.
• Each test should test just one thing (single behaviour, method, or function)
• All external dependencies should be mocked.
• The assumptions for each test should be clear and defined within the test method.
• name of the test method should be meaningful.
• Unit tests should be fast so that it could be run as often as required.

Why it’s so important to write good unit tests?

Short answer: BAD unit tests are not going to last long.

Long answer: If unit tests are of low quality, or in other words, if a unit test meets one or more of the following conditions,

• Tests are not easily understandable by a person other than the one who wrote it.
• Tests interdepend on each other causing multiple tests to fail if one test is broken.
• Unit test suit take ages to run
• … (the list goes on)

Maintaining those unit tests would become a nightmare in the long run.

Ultimately it would lead to ignoring all the tests one by one as they fail.

Don’t believe me?

Then you may want to read this open letter from an ignored test

Power of having good unit tests

• Allows merciless refactoring - extremely rewarding.
• Gives you instant visual feedback - oh that green light
• Helps document the specification effectively.
• Guides the design of the production code (especially when TDD is practiced).
• Maintaining the production code will be a breeze.
• Others will be so grateful that you wrote those unit tests (trust me )

That being said, you should not overdo it, because it takes time and effort to maintain unit tests.

TDD really helps in that aspect as well, because when you do it the other way around (i. e. write the code and then try to unit test it), you could easily end up having unnecessary tests.

Like anything, the key to TDD is practice.

But how do you practice?

TDD KATAs to the rescue.

Not a new one every day, but the same coding exercise until you get sick of it.

So, head over to this repository where you can find a list of Katas to practice and start now.

Want to learn how TDD is done in a Spring Boot application?

Check out the following course.

In this course you will learn how to write unit tests before implementing a single line of bussiness logic, and also how to write seperate integration tests, while building a REST API with Spring Boot.

<h2 class="center mg-bt-1 "><a href="/blog/junit-tutorial/" target="_blank">Unit testing with JUnit 4</a></h2>


<div class="center maxw-700" markdown="0">
    <a href="/blog/junit-tutorial/" target="_blank">
        
        <img loading="lazy"  class="shadow mg-2" src="/assets/img/thumb/JUnit.svg" alt="How to write great unit tests with JUnit" title="How to write great unit tests with JUnit" rel="share"   />

    </a>
</div>

<h2 class="center mg-bt-1 "><a href="/blog/mockito-tutorial/" target="_blank">Learn to mock with Mockito</a></h2>


<div class="center maxw-700" markdown="0">
    <a href="/blog/mockito-tutorial/" target="_blank">
        
        <img loading="lazy"  class="shadow mg-2" src="/assets/img/thumb/Mockito.svg" alt="Mockito Tutorial" title="Mockito Tutorial" rel="share"   />

    </a>
</div>