Test-Driven Development in Java/

...

/

Beginning Wordz

Beginning Wordz

Build your Wordz application by creating a test class and outlining its purpose.

We'll cover the following...

Let’s apply these ideas to our Wordz application. We’re going to start with a class that will contain the core of our application logic, one that represents a word to guess and that can work out the score for a guess.

Press + to interact

We begin by creating a unit test class, which immediately puts us into software design mode. What should we call the test? We’ll go with WordTest, as that outlines the area we want to cover—the word to be guessed.

Application structure

Typical Java project structures are divided into packages. The production code lives under src/main/java and the test code is located under src/test/java. This structure describes how production and test code are equally important parts of the source code while giving us a way to compile and deploy only the production code. We always ship test code with the production code when we’re dealing with source code, but for deployed executables, we only omit the tests. We’ll also follow the basic Java package convention of having a unique name for our company or project at the top level. This helps avoid clashes with library code. We’ll call com.wordz, named after the application.

Press + to interact
Application structure
Application structure

Defining tests

The next design step is to decide which behavior to drive out and test first. We always want a simple version of a happy path, something that will help drive out the normal logic that will most commonly execute. We can cover edge cases and error conditions later. To begin with, let’s write a test that will return the score for a single letter that’s incorrect:

  1. We have a test class WordTest to test the class Word:

Press + to interact
public class WordTest {  
}

  1. The name of the test gives us an overview of what the test is doing. To start our design, we decide to use a class called Word to represent our word. We also decide to supply the word to guess as a constructor parameter to our object instance of the class Word we want to create. We code these design decisions into the test:

Press + to interact
public class WordTest {  
    @Test
    public void oneIncorrectLetter () {
        new Word("A");
    }
}

  1. We use autocomplete at this point to create a new Word class in its own file. Double-check in src/main folder tree and not src/test.

  2. We create the file in the source tree inside the right package.

  3. Now, we rename the Word constructor parameter:

Press + to interact
public class Word {
    public Word(String correctWord) {
    // No Action
    }
}

  1. Next, we return to the test. We capture the new object as a local variable so that we can test it:

Press + to interact
@Test
public void oneIncorrectLetter () {
    var word = new Word("A");
}

The next design step is to think of a way to pass a guess into the Word class and return a score.

  1. Passing the guess in is an easy decision—we use a ...