Why Use TDD?

Why should you take this approach? There are several benefits:

• Writing a test at a time will help you focus and refine the requirements by correctly implementing one thing at a time.

• It’s a way to ensure a relevant organization for your code. For example, by writing a test first, you need to think hard about the public interfaces for your code.

• You are building a comprehensive test suite as you iterate through the requirements, which increases confidence that you are matching the requirements and also reduces the scope of bugs.

• You don’t write code that you don’t need (over-engineer) because you’re just writing code that passes the tests.

The TDD Cycle

The TDD approach roughly consists of the following steps in a cycle, as depicted in Figure 5-1:

1. Write a test that fails

2. Run all tests

3. Make the implementation work

4. Run all tests

Figure 5-1. TDD cycle

In practice, as part of this process, you must continuously refactor your code or it will end up unmaintainable. At this moment you know you have a suite of tests that you can rely on when you introduce changes. Figure 5-2 illustrates this improved TDD process.

Figure 5-2. TDD with refactoring

In the spirit of TDD, let’s start by writing our first tests to verify that addActions and count behave correctly, as shown in Example 5-3.

@Test
void shouldHaveNoRulesInitially() {
    final BusinessRuleEngine businessRuleEngine = new BusinessRuleEngine();

    assertEquals(0, businessRuleEngine.count());
}

@Test
void shouldAddTwoActions() {
    final BusinessRuleEngine businessRuleEngine = new BusinessRuleEngine();

    businessRuleEngine.addAction(() -> {});
    businessRuleEngine.addAction(() -> {});

    assertEquals(2, businessRuleEngine.count());
}

When running the tests, you will see that they fail with an UnsupportedOperationException, as shown in Figure 5-3.

Figure 5-3. Failing tests

All tests are failing, but that’s fine. It gives us a reproducible test suite that will guide the implementation of the code. Now can add some implementation code, as shown in Example 5-4.

public class BusinessRuleEngine {

    private final List<Action> actions;

    public BusinessRuleEngine() {
        this.actions = new ArrayList<>();
    }

    public void addAction(final Action action) {
        this.actions.add(action);
    }

    public int count() {
        return this.actions.size();
    }

    public void run(){
        throw new UnsupportedOperationException();
    }
}

You can now rerun the tests and they are passing! However, there’s one crucial operation missing. How do we write a test for the method run? Unfortunately, run() does not return any result. We are going to need a new technique called mocking to verify that the method run() operates correctly.

Modeling State

You may start by writing code that adds an action and refers to a local variable using an anonymous class as shown in Example 5-7, or using a lambda expression as shown in Example 5-8.

// this object could be created from a form
final Customer customer = new Customer("Mark", "CEO");

businessRuleEngine.addAction(new Action() {

    @Override
    public void perform() {
        if ("CEO".equals(customer.getJobTitle())) {
            Mailer.sendEmail("[email protected]", "Relevant customer: " + customer);
        }
    }
});

// this object could be created from a form
final Customer customer = new Customer("Mark", "CEO");

businessRuleEngine.addAction(() -> {
    if ("CEO".equals(customer.getJobTitle())) {
        Mailer.sendEmail("[email protected]", "Relevant customer: " + customer);
    }
});

However, this approach is inconvenient for several reasons:

1. How do you test the action? It’s not an independent piece of functionality; it has a hardcoded dependency on the customer object.

2. The customer object is not grouped with the action. It is a sort of external state that is shared around, leading to a confusing mix of responsibilities.

So what do we need? We need to encapsulate the state that is available to actions within the Business Rules Engine. Let’s model these requirements by introducing a new class called Facts, which will represent the state available as part of the Business Rules Engine, and an updated Action interface that can operate on facts. An updated unit test is shown in Example 5-9. The unit test checks that when the Business Rules Engine runs, the specified action is actually invoked with the Facts object passed as an argument.

@Test
public void shouldPerformAnActionWithFacts() {
    final Action mockAction = mock(Action.class);
    final Facts mockFacts = mock(Facts.class);
    final BusinessRuleEngine businessRuleEngine = new BusinessRuleEngine(mockedFacts);

    businessRuleEngine.addAction(mockAction);
    businessRuleEngine.run();

    verify(mockAction).perform(mockFacts);
}

To follow the TDD philosophy, this test will initially fail. You always need to run the tests to begin with to ensure that they fail, otherwise you may write a test that accidentally passes. To make the test pass you will need to update the API and implementation code. First, you’ll introduce the Facts class, which allows you to store a fact represented as a key and a value. The benefit of introducing a separate Facts class for modeling state is that you can control the operations available to your users by providing a public API, and also unit test the behavior of the class. For the time being, the Facts class will only support String keys and String values. The code for the Facts class is shown in Example 5-10. We chose the names getFact and addFact because they better represent the domain at hand (working with facts) rather than getValue and setValue.

public class Facts {

    private final Map<String, String> facts = new HashMap<>();

    public String getFact(final String name) {
        return this.facts.get(name);
    }

    public void addFact(final String name, final String value) {
        this.facts.put(name, value);
    }
}

You’ll now need to refactor the Action interface so that the perform() method can use a Facts object passed as an argument. This way it’s clear the facts are available within the context of the single Action (Example 5-11).

@FunctionalInterface
public interface Action {
    void perform(Facts facts);
}

Finally, you can now update the BusinessRuleEngine class to utilize the facts and the updated Action’s perform() method as shown in Example 5-12.

public class BusinessRuleEngine {

    private final List<Action> actions;
    private final Facts facts;

    public BusinessRuleEngine(final Facts facts) {
        this.facts = facts;
        this.actions = new ArrayList<>();
    }

    public void addAction(final Action action) {
        this.actions.add(action);
    }

    public int count() {
        return this.actions.size();
    }

    public void run() {
        this.actions.forEach(action -> action.perform(facts));
    }
}

Now that the Facts object is available to actions, you can specify arbitrary logic in your code that looks up the Facts object as shown in Example 5-13.

businessRuleEngine.addAction(facts -> {
    final String jobTitle = facts.getFact("jobTitle");
    if ("CEO".equals(jobTitle)) {
        final String name = facts.getFact("name");
        Mailer.sendEmail("[email protected]", "Relevant customer: " + name);
    }
});

Let’s look at some more examples. This is also a good opportunity to introduce two recent features in Java, which we explore in order:

• Local variable type inference

• Switch expressions

Local Variable Type Inference

Java 10 introduced variable local type inference. Type inference is the idea that the compiler can figure out the static types for you so you don’t have to type them. You saw an example of type inference earlier in Example 5-10 when you wrote

Map<String, String> facts = new HashMap<>();

instead of

Map<String, String> facts = new HashMap<String, String>();

This is a feature that was introduced in Java 7 called the diamond operator. Essentially, you can omit the type parameters of generics (in this case String, String) in an expression when its context determines them. In the preceding code, the lefthand side of the assignment indicates the keys and values of the Map should be Strings.

Since Java 10, type inference has been extended to work on local variables. For example, the code in Example 5-14 can be rewritten using the var keyword and local variable type inference shown in Example 5-15.

Facts env = new Facts();
BusinessRuleEngine businessRuleEngine = new BusinessRuleEngine(env);

var env = new Facts();
var businessRuleEngine = new BusinessRuleEngine(env);

By using the var keyword in the code shown in Example 5-15, the variable env still has a static type Facts and the variable businessRuleEngine still has the static type BusinessRuleEngine.

final Facts env = new Facts();

var env = new Facts();

final var env = new Facts()

Type inference helps reduce the amount of time taken to write Java code. However, should you use this feature all the time? It’s worth remembering that developers spend more time reading code than writing it. In other words, you should think about optimizing for ease of reading over ease of writing. The extent to which var improves this will always be subjective. You should always be focusing on what helps your teammates read your code, so if they are happy reading code with var then you should use it, otherwise not. For example, here we can refactor the code in Example 5-13 to use local variable type inference to tidy up the code as shown in Example 5-16.

businessRuleEngine.addAction(facts -> {
    var jobTitle = facts.getFact("jobTitle");
    if ("CEO".equals(jobTitle)) {
        var name = facts.getFact("name");
        Mailer.sendEmail("[email protected]", "Relevant customer: " + name);
    }
});

Switch Expressions

So far you’ve only set up actions with exactly one condition to handle. This is pretty limiting. For example, say you work with your sales team. They may record on their Customer Relationship Management (CRM) system different deals with different amounts that have different stages. A deal stage may be represented as an enum Stage with values including LEAD, INTERESTED, EVALUATING, CLOSED, as shown in Example 5-17.

public enum Stage {
    LEAD, INTERESTED, EVALUATING, CLOSED
}

Depending on the stage of the deal you can assign a rule that gives you the probability of winning the deal. Consequently, you can help the sales team with generating a forecast. Say for a particular team, LEAD has 20% probability to convert, then a deal at stage LEAD with amount of 1000USD will have a forecasted amount of 200USD. Let’s create an action to model these rules and return a forecasted amount for a particular deal as shown in Example 5-18.

businessRuleEngine.addAction(facts -> {
    var forecastedAmount = 0.0;
    var dealStage = Stage.valueOf(facts.getFact("stage"));
    var amount = Double.parseDouble(facts.getFact("amount"));
    if(dealStage == Stage.LEAD){
        forecastedAmount = amount * 0.2;
    } else if (dealStage == Stage.EVALUATING) {
        forecastedAmount = amount * 0.5;
    } else if(dealStage == Stage.INTERESTED) {
        forecastedAmount = amount * 0.8;
    } else if(dealStage == Stage.CLOSED) {
        forecastedAmount = amount;
    }
    facts.addFact("forecastedAmount", String.valueOf(forecastedAmount));
});

The code shown in Example 5-18 is essentially providing a value for each enum value available. A preferred language construct is the switch statement as it’s more succinct. This is shown in Example 5-19.

switch (dealStage) {
    case LEAD:
        forecastedAmount = amount * 0.2;
        break;
    case EVALUATING:
        forecastedAmount = amount * 0.5;
        break;
    case INTERESTED:
        forecastedAmount = amount * 0.8;
        break;
    case CLOSED:
        forecastedAmount = amount;
        break;
}

Note all the break statements in the code in Example 5-19. The break statement ensures that the next block in the switch statement is not executed. If you forget the break by accident, then the code still compiles and you get what’s called a fall-through behavior. In other words, the next block is executed and this can lead to subtle bugs. Since Java 12 (using the language feature preview mode) you can rewrite this to avoid the fall-through behavior and multiple breaks by using a different syntax for switch. switch can now be used as an expression, as illustrated in Example 5-20.

var forecastedAmount = amount * switch (dealStage) {
    case LEAD -> 0.2;
    case EVALUATING -> 0.5;
    case INTERESTED -> 0.8;
    case CLOSED -> 1;
}

Another benefit of this enhanced switch form, besides increased readability, is exhaustiveness. This means that when you use switch with an enum, the Java compiler checks that for all enum values there’s a corresponding switch label. For example, if you forget to handle the CLOSED case, the Java compiler would produce the following error:

error: the switch expression does not cover all possible input values.

You can rewrite the overall action using a switch expression as shown in Example 5-21.

businessRuleEngine.addAction(facts -> {
    var dealStage = Stage.valueOf(facts.getFact("stage"));
    var amount = Double.parseDouble(facts.getFact("amount"));
    var forecastedAmount = amount * switch (dealStage) {
        case LEAD -> 0.2;
        case EVALUATING -> 0.5;
        case INTERESTED -> 0.8;
        case CLOSED -> 1;
    }
    facts.addFact("forecastedAmount", String.valueOf(forecastedAmount));
});

Interface Segregation Principle

We would now like to develop an inspector tool that allows users of the Business Rules Engine to inspect the status of possible actions and conditions. For example, we would like to evaluate each action and associated condition in order to log them without actually performing the action. How do we go about this? The current Action interface is not sufficient because it doesn’t separate the code performed versus the condition that triggers that code. At the moment there’s no way to separate out the condition from the action code. To make up for this, we could introduce an enhanced Action interface that has a built-in functionality for evaluating the condition. For example, we could create an interface ConditionalAction that includes a new method evaluate() as shown in Example 5-22.

public interface ConditionalAction {
    boolean evaluate(Facts facts);
    void perform(Facts facts);
}

We can now implement a basic Inspector class that takes a list of ConditionalAction objects and evaluates them based on some facts, as shown in Example 5-23. The Inspector returns a list of reports that captures the facts, the conditional action, and the result. The implementation for the Report class is shown in Example 5-24.

public class Inspector {

    private final List<ConditionalAction> conditionalActionList;

    public Inspector(final ConditionalAction...conditionalActions) {
        this.conditionalActionList = Arrays.asList(conditionalActions);
    }

    public List<Report> inspect(final Facts facts) {
        final List<Report> reportList = new ArrayList<>();
        for (ConditionalAction conditionalAction : conditionalActionList) {
            final boolean conditionResult = conditionalAction.evaluate(facts);
            reportList.add(new Report(facts, conditionalAction, conditionResult));
        }
        return reportList;
    }
}

public class Report {

    private final ConditionalAction conditionalAction;
    private final Facts facts;
    private final boolean isPositive;

    public Report(final Facts facts,
                     final ConditionalAction conditionalAction,
                     final boolean isPositive) {
        this.facts = facts;
        this.conditionalAction = conditionalAction;
        this.isPositive = isPositive;
    }

    public ConditionalAction getConditionalAction() {
        return conditionalAction;
    }

    public Facts getFacts() {
        return facts;
    }

    public boolean isPositive() {
        return isPositive;
    }

    @Override
    public String toString() {
        return "Report{" +
                "conditionalAction=" + conditionalAction +
                ", facts=" + facts +
                ", result=" + isPositive +
                '}';
    }
}

How would we go about testing the Inspector? You may start by writing a simple unit test as shown in Example 5-25. This test highlights a fundamental issue with our current design. In fact, the ConditionalAction interface breaks the Interface Segregation Principle (ISP).

public class InspectorTest {

    @Test
    public void inspectOneConditionEvaluatesTrue() {

        final Facts facts = new Facts();
        facts.setFact("jobTitle", "CEO");
        final ConditionalAction conditionalAction = new JobTitleCondition();
        final Inspector inspector = new Inspector(conditionalAction);

        final List<Report> reportList = inspector.inspect(facts);

        assertEquals(1, reportList.size());
        assertEquals(true, reportList.get(0).isPositive());
    }

    private static class JobTitleCondition implements ConditionalAction {

        @Override
        public void perform(Facts facts) {
            throw new UnsupportedOperationException();
        }

        @Override
        public boolean evaluate(Facts facts) {
            return "CEO".equals(facts.getFact("jobTitle"));
        }
    }
}

What is the Interface Segregation Principle? You may notice that the implementation of the perform method is empty. In fact, it throws an UnsupportedOperationException. This is a situation where you are coupled to an interface (ConditionalAction) that provides more than what you need. In this case, we just want a way to model a condition—something that evaluates to either true or false. Nonetheless, we are forced to depend on the perform() method because it is part of the interface.

This general idea is the foundation of the Interface Segregation Principle. It makes the case that no class should be forced to depend on methods it does not use because this introduces unnecessary coupling. In Chapter 2, you learned about another principle, the Single Responsibility Principle (SRP), which promotes high cohesion. The SRP is a general design guideline that a class has responsibility over a single functionality and there should be only one reason for it to change. Although the ISP may sound like the same idea, it takes a different view. The ISP focuses on the user of an interface rather than its design. In other words, if an interface ends up very large, it may be that the user of that interface sees some behaviors it doesn’t care for, which causes unnecessary coupling.

To provide a solution that meets the Interface Segregation Principle, we are encouraged to separate out concepts in smaller interface that can evolve separately. This idea essentially promotes higher cohesion. Separating out interfaces also provides an opportunity for introducing names that are closer to the domain at hand, such as Condition and Action, which we explore in the next section.

What Is a Fluent API?

A Fluent API is an API that is explicitly tailored for a specific domain so that you can solve a specific problem more intuitively. It also embraces the idea of chaining method calls to specify a more complex operation. There are several high-profile Fluent APIs you may be already familiar with:

• The Java Streams API allows you to specify data processing queries in a way that reads more like the problem you need to solve.

• Spring Integration offers a Java API to specify enterprise integration patterns using a vocabulary close to the domain of enterprise integration patterns.

• jOOQ offers a library to interact with different databases using an intuitive API.

Modeling the Domain

So what is it that we want to simply for our business users? We’d like to help them specify a simple combination of “when some condition holds,” “then do something” as a rule. There are three concepts in this domain:

Condition

A condition applied on certain facts that will evaluate to either true or false.

Action

A specific set of operations or code to execute.

Rule

This is a condition and an action together. The action only runs if the condition is true.

Now that we’ve defined the concepts in the domain, we translate it into Java! Let’s first define the Condition interface and reuse our existing Action interface as shown in Example 5-26. Note that we could have also used the java.util.function.Predicate interface available since Java 8, but the name Condition better represents our domain.

@FunctionalInterface
public interface Condition {
    boolean evaluate(Facts facts);
}

Now the remaining question is how to model the concept of a rule? We can define a interface Rule with an operation perform(). This will allow you to provide different implementations of a Rule. A suitable default implementation of this interface is a class DefaultRule, which will hold a Condition and Action object together with the appropriate logic to perform a rule as shown in Example 5-27.

@FunctionalInterface
interface Rule {
    void perform(Facts facts);
}

public class DefaultRule implements Rule {

    private final Condition condition;
    private final Action action;

    public Rule(final Condition condition, final Action action) {
        this.condition = condition;
        this.action = action;
    }

    public void perform(final Facts facts) {
        if(condition.evaluate(facts)){
            action.execute(facts);
        }
    }
}

How do we create new rules using all these different elements? You can see an example in Example 5-28.

final Condition condition = (Facts facts) -> "CEO".equals(facts.getFact("jobTitle"));
final Action action = (Facts facts) -> {
      var name = facts.getFact("name");
      Mailer.sendEmail("[email protected]", "Relevant customer!!!: " + name);
};

final Rule rule = new DefaultRule(condition, action);

Builder Pattern

However, even though the code uses names that are close to our domain (Condition, Action, Rule), this code is fairly manual. The user has to instantiate separate objects and assemble things together. Let’s introduce what’s called the Builder pattern to improve the process of creating a Rule object with the appropriate condition and action. The purpose of this pattern is to allow the creation of an object in a simpler manner. The Builder pattern essentially deconstructs the parameters of a constructor and instead provides methods to supply each of the parameters. The benefit of this approach is that it allows you to declare methods with names that are suitable to the domain at hand. For example, in our case we’d like to use the vocabulary when and then. The code in Example 5-29 shows how to set up the Builder pattern to build a DefaultRule object. We’ve introduced a method when(), which supplies the condition. The method when() returns this (i.e., the current instance), which will allow us to chain up further methods. We’ve also introduced a method then(), which will supply the action. The method then() also returns this, which allows us to further chain a method. Finally, the method createRule() is responsible for the creation of the DefaultRule object.

public class RuleBuilder {
    private Condition condition;
    private Action action;

    public RuleBuilder when(final Condition condition) {
        this.condition = condition;
        return this;
    }

    public RuleBuilder then(final Action action) {
        this.action = action;
        return this;
    }

    public Rule createRule() {
        return new DefaultRule(condition, action);
    }
}

Using this new class, you can create RuleBuilder and configure a Rule using the methods when(), then(), and createRule() as shown in Example 5-30. This idea of chaining methods is a key aspect of designing a Fluent API.

Rule rule = new RuleBuilder()
        .when(facts -> "CEO".equals(facts.getFact("jobTitle")))
        .then(facts -> {
            var name = facts.getFact("name");
            Mailer.sendEmail("[email protected]", "Relevant customer: " + name);
        })
        .createRule();

This code looks more like a query and it leverages the domain at hand: the notion of a rule, when(), and then() as built-in constructs. But it’s not entirely satisfactory because there are still two awkward constructs the user of your API will have to encounter:

• Instantiate an “empty” RuleBuilder

• Call the method createRule()

We can improve this by coming up with a slightly improved API. There are three possible improvements:

• We’ll make the constructor private so that it can not be invoked explicitly by a user. This means that we will need to come up with a different entry point for our API.

• We can make the method when() static so it’s invoked directly and essentially short circuits the invocation to the old constructor. In addition, a static factor method improves discoverability of what’s the right method to use to set up Rule objects.

• The method then() will become responsible for the final creation of our DefaultRule object.

Example 5-31 shows the improved RuleBuilder.

public class RuleBuilder {
    private final Condition condition;

    private RuleBuilder(final Condition condition) {
        this.condition = condition;
    }

    public static RuleBuilder when(final Condition condition) {
        return new RuleBuilder(condition);
    }

    public Rule then(final Action action) {
        return new DefaultRule(condition, action);
    }
}

You can now simply create rules by starting with the RuleBuilder.when() method followed by the then() method as shown in Example 5-32.

final Rule ruleSendEmailToSalesWhenCEO = RuleBuilder
        .when(facts -> "CEO".equals(facts.getFact("jobTitle")))
        .then(facts -> {
            var name = facts.getFact("name");
            Mailer.sendEmail("[email protected]", "Relevant customer!!!: " + name);
        });

Now that we’ve refactored the RuleBuilder, we can refactor the Business Rules Engine to support rules instead of just actions, as shown in Example 5-33.

public class BusinessRuleEngine {

    private final List<Rule> rules;
    private final Facts facts;

    public BusinessRuleEngine(final Facts facts) {
        this.facts = facts;
        this.rules = new ArrayList<>();
    }

    public void addRule(final Rule rule) {
        this.rules.add(rule);
    }

    public void run() {
        this.rules.forEach(rule -> rule.perform(facts));
    }

}