With TDD, tests have essentially three purposes:

The first item, that of tests driving the design during coding, rather than an up-front process of thinking and modeling driving the design, is the defining characteristic of TDD. It's what made TDD such a revolutionary (not the same as "good") approach. TDD drives designs at a short-range, tactical level, leaving more strategic decisions to be handled elsewhere. Think of a blind man with a cane being able to detect what's immediately in front of him, as opposed to being able to see a truck heading straight at you, a bit further down the road.

Documentation isn't an inherent part of the TDD process. Result: no documentation.

The mantra that "the code is the design" means that very little design documentation may be written, making it difficult for newcomers to learn the details of the project. If they ask for a system overview, or which class is the main one for a particular screen or business function, being told to go and trawl through the unit tests (as "the tests are the design") isn't going to be too helpful. Enterprising individuals might well think to set up a project wiki and put some pages on there covering different aspects of the design. . . or they might not. Creation of design documentation isn't an inherent part of the process, so it's not likely to happen.

If it's not in JUnit, it doesn't exist...

The mindset of a test-first methodology is, as you'd expect, to write a test first. Then add something new to make the test pass, so you can "prove" that it's done (fans of Gödel's incompleteness theorems should look away now). Unfortunately, this can mean that just the "sunny day scenario" is proven to be implemented. All the "unexpected" stuff—different ways the user may traverse the UI, partial system failures, or out-of-bounds inputs and responses—remain unexpected because no one took the time to think about them in any structured, systematic kind of way.

BUT ...

There's been some discussion in the TDD world about the true nature of TDD tests,^[5], mainly centering around the question: "Are TDD tests true unit tests?" The quick and simple answer is: "Yes. No. Not really." TDD tests (also sometimes called programmer tests, usually to pair them up with customer tests, aka acceptance tests) have their own purpose; therefore, on a true test-first project the tests will look subtly different from a "classical" fine-grained unit test. A TDD unit test might test more than a single unit of code at a time. TDDer and Extremo Martin Fowler writes the following:

This actually puts TDD tests roughly halfway between classical unit tests (which DDT uses) and DDT's own controller tests (see Chapter 6). In this book, however, we'll keep on calling TDD tests "unit tests," as it's what the rest of the world generally calls them.

Acceptance tests also form part of the specification... or they would if we had acceptance tests (and if we had a specification). Unless you've layered another process on top of TDD (such as XP or Acceptance TDD), you'll be driving unit tests directly from the requirements/stories.

Confidence to make the continual stream of changes that is "design by refactoring". But is that confidence misplaced?

To rephrase the heading, a green bar means "all the tests I've written so far are not failing." When running unit tests through a test-runner such as that built into Eclipse, Flash Builder, IntelliJ, etc., if all your tests pass you'll see a green bar across the window: a sort of minor reward (like a cookie but not as tasty) that may produce an endorphin kick and the feeling that all's well with the world, or at least with the project.

Having covered your code with a thick layer of unit tests, the idea is that this notion of "all being well" should give you the confidence needed to be able to continuously refactor your code without accidentally introducing bugs. However, do take a read through Matt's "Green Bar of Shangri-La" article.^[7] (Hint: how do you know if you missed some unit tests?)

First you write a test, and then you write some code to make the test pass. Then you refactor the code to improve the design, without breaking any tests that have been written so far. Thus, the design emerges as you grow the code base incrementally through the test/code/refactor cycle. For non-TDDers, this is roughly analogous to banging your forehead against a wall to make sure that you're able to feel pain, before you start building the wall, whose existence you will then verify by banging your forehead against it. Of course you need a "mock wall" to bang your forehead against, since the real wall doesn't exist yet...we like to call this "Constant Refactoring After Programming" since it has such a descriptive acronym.

It's absolutely within the TDD "doctrine" to spend time up-front thinking through the design, even sketching out UML diagrams—though ideally this should be in a collaborative environment, e.g., a group of developers standing at a whiteboard. (That said, doing a lot of up-front design and writing all those billions of tests and refactoring the design as you go would represent a lot of duplicated effort.)

In theory, this means upfront design will get done, but in practice TDDers (who often do TDD in conjunction with SCRUM) find that upfront design is not on the deliverable list for the current sprint.

The test-first philosophy underlying TDD is that before you write any code, you first write a test that fails. Then you write the code to make the test pass. The net result is that aggressive refactoring—which will be needed by the bucket-load if you take this incremental approach to design—is made safer by the massive number of tests blanketing the code base. So the tests double as a design tool and as heavily leaned-upon regression tests.

TDD also doesn't really distinguish between "design level" (or solution space) tests and "analysis level" (or problem space) tests.^[8]

From the Department of Redundancy Department, TDD is Too Damn Difficult. The net effect of following TDD is that everything and its hamster gets a unit test of its own. This sounds great in theory, but in practice you end up with an awful lot of redundant tests.^[9] TDD has an image of a "lightweight" or agile practice because it eschews the notion of a "big design up-front," encouraging you to get coding sooner. But that quick illusion of success is soon offset by the sheer hard work of refactoring your way to a finished product, rewriting both code and tests as you go.

Let's consider a simple Login user story:

It feels like there's some missing detail here, so you and your pair-programming pal Loretta go in search of Tim, the on-site customer.

"Ah, that's slightly more involved," Tim explains. "There's more to it than simply logging the user in. You need to see it from both the end-user's perspective and the web site owner's perspective. So, as a web site owner, I'm interested in making sure freeloading users can't get access to paid-for functionality, that they're channeled through a revenue-maximizing path, and that the site isn't susceptible to brute-force attempts to crack users' passwords."

"And you'd want users to feel secure, too," you add, and Tim nods.

You and Loretta head back to the programmer's palace and expand the user story into a more detailed set:

You argue briefly about whether this is really just one user story with added detail, or two—or three—separate stories. Then you agree to simply move on and start coding.

A PEEK AT THE ANSWER

Figure 2-1 shows how we'd normally design something like a web site login using a sequence diagram (an ICONIX Process design would be more "domain driven" as we'll see in the next chapter):

Figure 2-1. Sequence diagram for a web site login process

The design in Figure 2-1 is pretty simple stuff, really. You'd think designing a system like this wouldn't be very difficult to accomplish, especially with as popular a method as TDD. But, as you'll see in the remainder of this chapter, if we actually follow TDD (instead of drawing the simple sequence diagram that you see in Figure 2-1) it takes a whole chapter's worth of refactoring and tail-chasing to get to the final code shown in Figure 2-2.

Figure 2-2. Final code for a web site login solution

In other words, we're about to spend a ton of work getting to not much more than 20 lines of code in the remainder of this chapter. It all "feels" somehow correct as you're coding it, as the focus is on detecting poor design and improving it incrementally, and the green bar continually lights up, like a reward given to a hamster for drinking from the correct Kool-Aid dispenser. The endorphins are rollin' and the project is tricklin' along... except... at the end of the day, after all that effort, only 20 lines of code have been written.

If you're familiar with the ICONIX Process, or use cases in general, we suspect you'll already have equated these stories with high-level requirements. A natural next step would be to expand these into use cases, as the stories by themselves really don't address a number of questions that will spring up while the system is being implemented: what should happen if a wrong password is entered? (Is a different page displayed with "forgot password" and "create new account" links?) What page is the user taken to upon being logged in? What happens if the user attempts to view a page without being logged in? (Presumably he should be redirected to the login page, but is this definitely what the customer wants?) And so on. These are the sorts of questions that the ICONIX Process (and therefore DDT) encourage you to think about early on, and thus to factor into the design.

But more about that later. For now, fasten your seatbelt, as this chapter is about to dive down the rabbit-hole into "unit test wonderland." Let's get back to our intrepid pair of TDDers, who are now ready to code.

Before leaping into the code, it's normal to give a little thought to the design. You want the system to accept a login request—presumably this means that the user will enter a username and password. You may need to send Loretta back to extract more details from the on-site customer. But then what? How will the password be checked?

Some collaborative white-boarding produces the sketch shown in Figure 2-3.

Figure 2-3. Initial design sketch for the Login story

LoginAction is a generic, Spring Framework-esque UI action class to handle incoming web requests—in this case, a login request. It accepts two input values, the username and password, and simply hands the parameters on to a class better suited to handle the login request.

LoginManager accepts the username and password, and will need to make an external call to a RESTful service in order to validate the username and password. If validation fails, a ValidationException is thrown, and caught by the LoginAction, which sends a "FAIL" response back to the user. We also suspect that UserAccount will be needed at some point, but we hope to find out for sure when we begin coding.

Let's take a quick look at the project structure. Using Eclipse we've created a project called "LoginExample-TDD," which gives us the following folders:

LoginExample-TDD
   |__ src
   |__ test
   |__ bin

All the production code will go in packages beneath "src," all the unit tests will go into "test," and the compiled code will go into "bin."

Given the white-boarded design sketch in Figure 2-1, it makes sense to focus on LoginManager first. So we'll start by creating a LoginManager test class:

import static junit.framework.TestCase.*;
import org.junit.Test;

public class LoginManagerTest extends TestCase {

    @Test
    public void login() throws Exception {
    }

}

So far, so good. We've created a test skeleton for the login() method on LoginManager, which we identified during the brief design white-boarding session. We'll now add some code into this test, to create a LoginManager instance and attempt a login:

@Test
public void login() throws Exception {
    LoginManager manager = new LoginManager();
    try {
        manager.login("robert", "password1");
    } catch (LoginFailedException e) {
        fail("Login should have succeeded.");
    }
}

At this stage, Eclipse's editor has become smothered with wavy red lines, and compilation certainly fails (see Figure 2-4).

Figure 2-4. All dressed up with nowhere to go ... this test needs some code to run against.

This compilation failure is a valid stage in the TDD process: the test compilation errors tell us that some code must be written in order to make the test pass. So let's do that next, with two new classes:

public class LoginManager {
    public void login(String username, String password)
    throws LoginFailedException {
    }
}

public class LoginFailedException extends Exception {
}

The code now compiles, so—being eager-beaver TDDers—we rush to run our new unit test straightaway, fully expecting (and hoping for) a red bar, indicating that the test failed. But surprise! Look at Figure 2-5. Our test did not successfully fail. Instead, it failingly succeeded.

Oops, the test passed when it was meant to fail! Sometimes a passing test should be just as disconcerting as a failing test. This is an example of the product code providing feedback into the tests, just as the tests provide feedback on the product code. It's a symbiotic relationship, and it answers the question, what tests the tests? (A variant of the question, who watches the watchers?)

Figure 2-5. Green bar—life is good. Except... what's that nagging feeling?

Following the process strictly, we now add a line into the code to make the test fail:

public void login(String username, String password)
throws LoginFailedException {
    throw new LoginFailedException();
}

The login() method simply throws a LoginFailedException, indicating that all login attempts currently will fail. The system is now pretty much entirely locked down: no one can login until we write the code to allow it. We could alternatively have changed the first test to be "@Test loginFails()" and pass in an invalid username/password. But then we wouldn't have been implementing the basic pass through the user story first—to enable a user to log in successfully. At any rate, we've now verified that we can indeed feel pain in our forehead when we bang it against a wall!

Next, let's add some code to make the test pass:

public void login(String username, String password)
throws LoginFailedException {
    if ("robert".equals(username)
     && "password1".equals(password)) {

return;
     }
     throw new LoginFailedException();
}

If we re-run the test now, we get a green bar, indicating that the test passed. Does it seem like we're cheating? Well, it's the simplest code that makes the test pass, so it's valid—at least until we add another test to make the requirements more stringent:

@Test
public void anotherLogin() throws Exception {
    LoginManager manager = new LoginManager();
    try {
        manager.login("mary", "password2");
    } catch (LoginFailedException e) {
        fail("Login should have succeeded.");
    }
}

We now have two test cases: one in which valid user Robert tries to log in, and another in which valid user Mary tries to log in. However, if we re-run the test class, we get a failure:

junit.framework.AssertionFailedError: Login should have succeeded.
        at com.softwarereality.login.LoginManagerTest.anotherLogin(LoginManagerTest.java:24)

Now, clearly it's time to get real and put in some code that actually does a login check.

The real code will need to make a call to a RESTful service, passing in the username and password, and get a "login passed" or "login failed" message back. A quick instant-message to the relevant middleware/single-sign-on (SSO) team produces a handy "jar" file that encapsulates the details of making a REST call, and instead exposes this handy interface:

package com.mymiddlewareservice.sso;

public interface AccountValidator {

    public boolean validate(String username, String password);
    public void startSession(String username);
    public void endSession(String username);
}

The library also contains a "black-box" class, AccountValidatorFactory, which we can use to get at a concrete instance of AccountValidator:

public class AccountValidatorFactory {
    public static AccountValidator getAccountValidator() {...}
}

We can simply drop this jar file into our project, and call the middleware service in order to validate the user and establish an SSO session for him or her. Utilizing this convenient library, LoginManager now looks like this:

public class LoginManager {
    public void login(String username, String password)

throws LoginFailedException {
        AccountValidator validator =
            AccountValidatorFactory.getAccountValidator();
        if (validator.validate(username, password)) {
            return;
        }
        throw new LoginFailedException();
    }
}

If we were to re-run the tests now, the call to AccountValidator would make a network call to the remote SSO service and validate the username and password... so the test should pass quite happily.

But wait, is that the screeching halt of tires that you can hear?

This raises an important issue with unit testing in general: you really don't want your tested code to be making external calls during testing. Your unit test suite will be executed during the build process, so relying on external calls makes the build more fragile: suddenly it's dependent on network availability, servers being up and working, and so forth. "Service not available" shouldn't count as a build error.

For this reason, we generally go to great lengths to keep the unit-tested code insular. Figure 2-6 shows one way this could be done. In the sequence diagram, LoginManager checks whether it's running in the "live" environment or a unit-test/mock environment. If the former, it calls the real SSO service; if the latter, it calls a mock version.

Figure 2-6. A common anti-pattern: the code branches depending on which environment it's in.

Yikes. This would quickly become a nightmare of "if-else if" statements that check whether this is a live or test environment. Production code would become more complex as it becomes littered with these checks every time it needs to make an external call, not to mention special-handling code to return "dummy" objects for the tests' purposes. You really want to place as few restrictions and stipulations (aka hacks, workarounds) on the production code as possible—and you definitely don't want the design to degrade in order to allow for unit testing.

Luckily, there's another way that also happens to promote good design. So-called mock object frameworks such as JMock, EasyMock, and Mockito^[11] use special magic (okay, Java reflection and dynamic proxies behind the scenes) to create convenient, blank/non-functioning versions of classes and interfaces. For this example, we'll use JMock (we also use Mockito later in the book).

Going back to our LoginManagerTest class, we make it "JMock-ready" using an annotation and a context:

@RunWith(JMock.class)
public class LoginManagerTest  {
    Mockery context = new JUnit4Mockery();

Re-running the test now—and getting the same error as earlier—you can verify that the test is now going through JMock by scanning through the stack trace for the AssertionFailedError:

junit.framework.AssertionFailedError: Login should have succeeded.
        at com.softwarereality.login.LoginManagerTest.anotherLogin(LoginManagerTest.java:32)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
        at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:37)

Creating a mock instance of AccountValidator is pretty straightforward:

validator = context.mock(AccountValidator.class);

The next problem is how to get LoginManager to use this mock instance instead of the production version of AccountValidator returned by AccountValidatorFactory. In the LoginManager code we just wrote, the login() method directly calls AccountValidatorFactory.getAccountValidator(). We have no "hook" with which to tell it to use our version instead. So let's add a hook:

public class LoginManager {

    private AccountValidator validator;

    public void setValidator(AccountValidator validator) {
        this.validator = validator;
    }

    synchronized AccountValidator getValidator() {
        if (validator == null) {
            validator = AccountValidatorFactory.getAccountValidator();
        }
        return validator;
    }

public void login(String username, String password)
    throws LoginFailedException {
        if (getValidator().validate(username, password)) {
            return;
        }
        throw new LoginFailedException();
    }
}

This version uses a little bit of dependency injection (DI) to allow us to inject our own flavor of AccountValidator. Before the login() method is called, we can now set an alternative, mocked-out version of AccountValidator. The only change inside login() is that instead of using the validator member directly, it calls getValidator(), which will create the "real" version of AccountValidator if we haven't already injected a different version.

The complete login() test method now looks like this:

@Test
public void login() throws Exception {
    final AccountValidator validator = context.mock(AccountValidator.class);
    LoginManager manager = new LoginManager();
    manager.setValidator(validator);

    try {
        manager.login("robert", "password1");
    } catch (LoginFailedException e) {
        fail("Login should have succeeded.");
    }
}

Running the test still causes a red bar, however. This is because the new, mocked-out AccountValidator.validate() method returns false by default. To make it return true instead, you need to tell JMock what you're expecting to happen. You do this by passing in one of its appropriately named Expectations objects into the context:

context.checking(new Expectations() {{
    oneOf(validator).validate("robert", "password1"); will(returnValue(true));
}});

This code snippet is saying: "During the test, I'm expecting one call to validate() with the arguments "robert" and "password1", and for this one call I want the value true to be returned. In fact, this is one of JMock's great strengths—it allows you to specify exactly how many times you're expecting a method to be called, and to make the test fail automatically if the method isn't called at all, is called the wrong number of times, or is called with the wrong set of values.

For our immediate purposes, however, this is just a pleasant bonus: at this stage we're interested only in getting our mock object to return the value we're expecting.

Re-running the code with the new Expectations in place results in a green bar. We'll now need to do the same for the other test case—where we're passing in "mary" and "password2". However, simply repeating this technique will result in quite a bit of duplicated code—and it's "plumbing" code at that, very little to do with the actual test case. It's time to refactor the test class into something leaner.

We'll start by refactoring the test code, as that's our immediate concern. However, the real point of this exercise is to see the product code's design emerge as you add more tests and write the code to make the tests pass.

Here's the refactored test code:

@RunWith(JMock.class)
public class LoginManagerTest  {

    Mockery context = new JUnit4Mockery();
    LoginManager manager;
    AccountValidator validator;

    @Before
    public void setUp() throws Exception {
        validator = context.mock(AccountValidator.class);
        manager = new LoginManager();
        manager.setValidator(validator);
    }

@After
    public void tearDown() throws Exception {
        manager.setValidator(null);
        manager = null;
        validator = null;
    }

    @Test
    public void login() throws Exception {
        context.checking(new Expectations() {{
            oneOf(validator).validate("robert", "password1"); will(returnValue(true));
        }});

        try {
            manager.login("robert", "password1");
        } catch (LoginFailedException e) {
            fail("Login should have succeeded.");
        }
    }

    @Test
    public void anotherLogin() throws Exception {
       context.checking(new Expectations() {{
           oneOf(validator).validate("mary", "password2"); will(returnValue(true));
       }});

       try {
           manager.login("mary", "password2");
       } catch (LoginFailedException e) {
           fail("Login should have succeeded.");
       }
    }
}

We've created @Before and @After fixtures, which are run before and after each test case to set up the mock validator and the LoginManager, which is the class under test. This saves having to repeat this setup code each time. There's still some work that can be done to improve the design of this test class, but we'll come back to that in a moment. Another quick run through the test runner produces a green bar—looking good. But so far, all we've been testing for is login success. We should also pass in some invalid login credentials, and ensure that those are handled correctly. Let's add a new test case:

@Test( expected = LoginFailedException.class )
public void invalidLogin() throws Exception {
    context.checking(new Expectations() {{
        oneOf(validator).validate("wideboy", "blagger1"); will(returnValue(false));
    }});

    manager.login("wideboy", "blagger1");
}

This time, that old trickster Wideboy is trying to gain access to the system. But he won't get very far—not because we have a tightly designed SSO remote service running encrypted over SSL, but because our mock object has been set to return false. That'll show 'im! Stepping through the code, the first line uses a JUnit 4 annotation as with the other test methods; however, this time we've also specified that we're expecting the LoginFailedException to be thrown. We're expecting this exception to be triggered because the mock object will return false, indicating a login failure from the mocked-out SSO service. The code that's actually under test is the login() method in LoginManager. This test demonstrates that it's doing what's expected.

THE MAD HATTER'S REFACTORING PARTY^[14]

Alice, not knowing what else to do, and feeling somewhat shaky again after hearing about designs figuring themselves out from code, decided to follow the rabbit for a while. On they went, the rabbit pausing every few feet to iterate around in a circle a few times. Eventually, the rabbit, rushing ahead at top speed, pulled far enough ahead that Alice couldn't see him anymore.

Alice kept walking, and after a time she came to a clearing where she saw the rabbit, along with a large mouse and a little man wearing a big hat, all working furiously over a table and some chairs. When Alice walked up, all the legs from the table and chairs were sitting in a big pile on the ground. Alice watched as the Hatter, the rabbit, and the dormouse each grabbed four legs from the pile and screwed them into a chair. The problem was that the legs were of different lengths, and Alice watched in fascination as they each finished assembling their chair, turned it over, and sat down. The chairs often tipped over, what with the legs being of different lengths and all, and when this happened they all yelled out in unison, "Failed the unit test," flipped the chairs back over, and began unscrewing the legs and tossing them back onto the pile.

"What kind of game are you playing?" asked Alice.

"It's not a game, we're refactoring the furniture," replied the Hatter.

"Why don't you read the documentation for assembling the chairs?" asked Alice. "It's sure to specify which legs should go on which chairs."

"It's oral documentation," said the Hatter.

"Oh. You mean you don't have any."

"No," said the Hatter. "Written documentation is for cowards. We can refactor very quickly, so we can be brave enough to let the design figure itself out," he added.

"Oh, yes. The rabbit said I should ask you about that," said Alice. "How can designs figure themselves out from code?"

"You poor, ignorant child," said the Hatter, in quite a condescending tone. "The code is the design, don't you see? Perhaps you'd better let the Duchess explain it to you."

He resumed refactoring the chairs.

Looking at the last three test methods, you should see that there's something of a pattern of repeated code emerging, despite our recent refactoring. It would make sense to create a "workhorse" method and move the hairy plumbing code—setting the test case's expectations and calling LoginManager—into there. This is really just a case of moving code around, but, as you'll see, it makes a big difference to the test class's readability. Actually, we end up with two new methods: expectLoginSuccess() and expectLoginFailure().

Here are our two new methods:

void expectLoginSuccess(final String username, final String password) {
    context.checking(new Expectations() {{
        oneOf(validator).validate(username, password); will(returnValue(true));
    }});
    try {
        manager.login(username, password);
    } catch (LoginFailedException e) {
        fail("Login should have succeeded.");
    }
  }

  void expectLoginFailure(final String username, final String password) throws
LoginFailedException {
        context.checking(new Expectations() {{
            oneOf(validator).validate(username, password); will(returnValue(false));
        }});
        manager.login(username, password);
  }

Here's what the three refactored test methods now look like:

@Test
public void login() throws Exception {
    expectLoginSuccess("robert", "password1");
}

@Test
public void anotherLogin() throws Exception {
    expectLoginSuccess("mary", "password2");
}

@Test( expected = LoginFailedException.class )
public void invalidLogin() throws Exception {
    expectLoginFailure("wideboy", "blagger1");
}

All of a sudden, each test case looks very focused on purely the test values, without any of the plumbing code hiding the purpose or expectations of the test case. Another quick re-run of the tests produces a green bar (see Figure 2-7) so the change doesn't appear to have broken anything.

Figure 2-7. We refactored the code (again), so we re-run the tests to make sure nothing's broken.

Although UML modeling is sometimes seen as anathema to TDD (though by a shrinking minority, we hope), we took advantage of Enterprise Architect (EA)'s reverse engineering capability to vacuum up the new source code into a class model—see Figure 2-8. We also put together a quick sequence diagram to show how the code interacts—see Figure 2-9. Note that these diagrams might or might not be created on a real TDD project. We'd guess probably not, especially the sequence diagram. After all, who needs documentation when there's JUnit code?

Figure 2-8. The product code, reverse-engineered into EA

Notice that throughout this coding session, we haven't even attempted to write any tests for the remote SSO service that our code will call at production time. This is because—at this stage, at least—the SSO service isn't what we are developing. If it turns out that there's a problem in the SSO code, we'll have enough confidence in our own code—as it's covered with unit tests—to safely say that the problem must be inside the "black box" service. This isn't so much "it's their problem, not ours," as that's distinctly territorial, but rather it helps to track down the problem and get the issue resolved as quickly as possible. We can do this because we've produced well-factored code with good unit-test code coverage.

Having said that, at some stage we do want to prove that our code works along with the SSO service. In addition to good old-fashioned manual testing, we'll also write an acceptance test case that tests the system end-to-end.

Figure 2-9. A sequence diagram showing the product behavior that's under test