Chapter 11. System Boundary

“You cannot always control what goes on outside. But you can always control what goes on inside.”

Wayne Dyer

The triad works on stories that involve interfaces to external systems. Tom explicates on test doubles and mocks.

---

External Interfaces

Debbie starts off, “Now that we’ve determined correctly how much to charge the customer, let’s move on to the Submit Charge story. I see the high-level tests for this were as follows.”

“Cathy, would you explain how charging works,” Debbie asked.

Cathy answers. “I’ve talked with my bank and the credit-card processing company. The rental system needs to send a charge to the credit-card processor, like our current charge card reader does. The processor returns a message that the charge is accepted or declined. At the end of the day, the processor makes a bank transfer for all the charges during a day less any charge-backs and the processing fee. Don’t get me started on the size of that processing fee. Anyway, I can go online and see the transfers that were made during the previous days. If I need to, I can get a listing of all the charges that were made from the credit-card processor. I can also confirm with my bank to see that the transfer was received.”

Debbie draws a diagram (see Figure 11.1). She says, “This is my understanding of what you said. Am I right?”

Figure 11.1. Credit-Card Charge Processing

“That looks good to me,” Cathy replies.

Tom states, “Do you have in mind some acceptance tests for this workflow?”

“Yes,” Cathy replies. “It seems like there are two acceptance tests. The first is to verify that the credit-card processor got all the transactions that the rental system said it sent. And the second makes sure the bank got all the transfers that the processor said it sent. So the first one would be this.”

Cathy continues, “As finance manager, I’ve gotten this report of credit-card charges many times, but I’ve only been concerned with the dollar numbers. The three of us should see if you two need to know about anything else on the report. For example, there is a column for transaction ID on the report. That might be useful.”

Tom replies, “That would be great. We could run this test as an acceptance test for the system. In that case, we would do a manual comparison of the two lists, and we could incorporate the comparison into part of daily process. If we did that, Debbie could create a way to compare the information you downloaded to the list that the rental system generates. We could create a story to do that. Have you ever had a problem with a charge not showing up?”

Cathy answers, “There may have been one or two, but it’s never been an issue that crossed my mind. The effort of calling up the credit-card processor to check on a $2 charge isn’t really worth it. So I think we can put that story on hold.”

“Oh, I forgot,” Cathy exclaimed. “What about charge-backs? How should we handle those?”

Debbie replied, “We can give it to you in whatever form is easiest for you to match up. If the transactions from the credit-card processor are listed separately as charges and charge-backs, we’ll give you two lists. If they are listed on one list, say sorted by the time, we’ll give you one list. Our job is to create a system that makes it easy for you to do your job.”

Tom queries, “Cathy, is there another test you apply to the flow?”

Cathy replies, “There should be one to verify that a transfer was made each day and that the bank received it. This step follows after the first one. So the test would be this.”

Cathy continues, “I do this every now and then for a whole set of days. In the past few years, I’ve never seen a transfer for the amount absent from the bank statement. There was one time it was off by a day, so there were two transfers on the same day. I’ll continue to do so for the present. We can put off automating this process until later.”

Cathy concludes, “This whole idea of charging our customers automatically instead of handling cash is appealing. Of course, we may lose a few customers who don’t want to have their rentals appear on their credit-card statements. I know of one whose spouse would become really angry, to put it mildly, if the amount of money spent on CD rentals became known. But the savings in the clerk’s time in collecting money and balancing a cash drawer, my time in taking deposits to the bank, and the insurance costs of not having money on the premises will more than make up for any lost rentals. Please get going on Submit Charge pronto.”

More Details

Debbie says, “I think we’ve got the big picture for this story. Let’s take a look at more details. From the results of the Check-In story [Chapter 10, “User Story Breakup”], we have a rentals fee to be charged for a particular day. This fee becomes the input for the next step: Submit a charge to the credit-card processor. An additional test for Check-In appears as follows.”

---

External Interface Tests

Debbie starts off, “So far, we can create the values for a card charge and confirm that the charge is received by the credit-card processor. However, there is still one missing piece: having the rental system actually submit the charge. Cathy, can you go through the possibilities from the business side? How do you submit a card charge now?”

Cathy replies, “The clerk enters the amount and swipes the card. Either a card charge is confirmed, or it is declined. Based on how we’ve been expressing tests, I can see two cases.”

“With the manual system, if a charge is declined, the clerk asks for another card. I guess that will be harder to do with this application. I’ll think about what to do for the second condition and get back to you on that.”

Debbie says, “That’s fine. It’ll take a little time to get the information I need from the credit processor.”

Component Tests

After a while, the triad meets again. Debbie starts off, “The credit-card processor has coding standards and protocols on how to submit a charge and what messages are transmitted between a merchant’s system and a retailer’s system. Once I understood some of the issues, I determined I needed a component that would handle the charge submission. I created component tests that my code needed to pass. Using your cases, they are as follows.”

“I made up one for charge declined: The input information includes a credit number that should be declined.”

“Now how all this information is formatted and transmitted is technical and detailed. I’ll be using test-driven development with unit tests to design the code that passes this component test. As you can see, the tests have a lot of detail for the card charge. The reason I’m showing them to you is they bring up business questions. A simple one is how do you want to phrase the Charge Identification that appears on the customer’s statement?”

Cathy replies, “That looks okay to me. What else?”

Debbie continues, “I found that there are a lot of reasons a card can be rejected. Many of the rejections are for reasons such as the expiration date being in a bad format. These types of issues I will handle in the component. They are standard programming concerns. But I’ve come up with some results that call for a business decision. I may come across a few more when I get into the details.”

Debbie says, “You need to decide what should be done in each of these cases.”

Cathy works through the options and comes up with the following actions.

Debbie continues, “Tom and I will come up with tests that generate all these results to make sure the action occurs. Details will need to be gathered on the wording of the dialog boxes and e-mail messages. But those are display concerns, not business rule issues.”

Tom asks, “Debbie, what happens if the network goes down in the middle of processing a credit-card transaction? You and I both know that periodically the Internet seems to come to a grinding halt, which is the equivalent of going down.”

Debbie replies, “I’ll just queue up the charges and submit them when it does come back up. I’ll add a component test to make sure that is what happens.”

Tom answers, “What if it doesn’t come up for full day?”

Debbie counters, “I can send them when it does. But the date of the charge will not match the date of the return. Cathy, will that work for you?”

Cathy replies, “We faced the same problem when the phone line was down. The clerks had to write down the credit-card numbers and submit them the next day. We did have one customer who knew the line was down, so he used an invalid card. But you can only do so much. Submitting them when you can sounds fine to me.”

Test Doubles and Mocks

Cathy has a burning question. “How are you going to run all these tests? Are you going to use your credit-card number? How can you make sure that a credit card is rejected for a particular reason?”

Debbie answers, “One way to do it is to use Tom’s cards. He’s maxed out on some of them. But the banks might get after Tom for trying to use those credit cards. So we will use what many developers call a test double [Meszaros01]. A test double is something that stands in for a real system when tests are being run. It comes from the idea of a double who stands in for the real actor when shooting a movie.”

“A test double encompasses a couple of other concepts that you might hear Tom and me or other developers throw around. They are mock [Hillside01], stub, and fake. [Craig01]. The mock term comes from Alice in Wonderland by Lewis Carroll. You may remember the line:”

“Once,” said the Mock Turtle at last, with a deep sigh, “I was a real Turtle.”

Debbie continues, “I’m not going to get into the differences and details between these three terms. That’s something that developers love to discuss on blogs. The key is that using test doubles makes a system easier to test. The credit-card processor provides a test double. Instead of connecting to the real credit-card system, you connect to the test double that’s provided. The test double accepts credit-card charges and returns confirmations just like the real system.”

“To get the test double to return different results, you send it different combinations of values. For example, with your processor, you send a charge for the credit-card number 4111111111111111. This causes a charge to be declined.”

“If there wasn’t already a test double, I would write one myself. In fact, whenever there is some external interface to a system, I usually create a test double. In this case, as long as I can have all the different results sent back to me, I don’t need my own test double. I haven’t checked, but I’m sure there is some number I can send that would create a result that puts up a dialog to call the police. If not, I’ll bet one of Tom’s cards would do that.”

“To test the complete system, we do need to make some credit-card charges all the way from the return of a CD through seeing it on the credit charges processed list. We’ll use your card for a good one and use an invalid number to see if things are rejected.”

---

What Is Real?

A system in production—“the real world”—interacts with many things outside itself. It may ask an external service for information or to do a calculation or perform an action. Events may occur at random times and in random sequences that require a response from the system. In production, there is usually no control over these external interactions. But in testing, control is needed so that the same test case can be performed over and over again and still get the same expected result.

An external service may provide the same information every time it is requested. (In programmers’ terms, it is idempotent.) Even so, the developer may want to create a test double for it so the tests run faster. The context of our system is shown in Figure 11.2.

Figure 11.2. System Context

You often need control of time to get tests to run the same way. The test double that the credit-card processor provides allows for repeatable tests. If there were random events that the system had to respond to, a test double for them would be created.

As an example, suppose several clerks were doing check-outs and check-ins at the same time. The developer could simulate a sequence of check-outs and check-ins. A test double would generate a series of actions like the following sequence to see if the implantation could handle it.

---

Story Map of Activities

As described in Chapter 7, “Collaborating on Scenarios,” a story map can organize various stories into activities. For the stories so far, the map could look like the following (see Figure 11.3). As soon as the top story for each activity is completed, the entire workflow from check-in through seeing the entry in the card processor’s report can be executed.

Figure 11.3. Check-In Story Map

---

Summary

• Create acceptance tests for external interfaces.

• Developers can create component tests for internal processing functionality.

• Details from lower levels may generate questions that need customer answers.

• Use test doubles or mocks for external interfaces to simplify testing.

• Create story maps to organize stories into workflows.