- A Sample Business Rule
- Implementing the Acceptance Tests
- Testing Process
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing the Acceptance Tests
Tom and Debbie needed to apply these tests to the implementation they were developing. There were at least four possible ways to do this. First, Tom could create a test script that operates manually at the user interface level. Second, Debbie could create a test user interface that allows her or Tom to check the appropriate discount percentages. Third, Debbie could perform the tests using a unit testing framework. Fourth, Tom and Debbie could implement the tests with an acceptance test framework. Following are examples of how they could use each of these possibilities.
Test Script
In this case, the program has a user interface that allows a customer to enter an order. The user interface flow is much like Amazon or other order sites. The user enters an order and a summary screen appears, such as the one in Figure 4.1.
)
Figure 4.1 Order Interface
What Tom would have to do is to create a script that either he or Debbie would follow to test each of the six cases in the Discount Calculation table. He might start by computing what the actual discount amount should be for each case. Unless the Order Summary screen shows this percentage, this value is the only output Tom can check to ensure the calculation is correct. Here is an addition to the table that shows the amounts he needs to look for.
|
Discount Calculation |
||||
|
Item Total |
Customer Rating |
Discount Percentage? |
Discount Amount? |
Notes |
|
$10.00 |
Good |
0% |
$0.00 |
|
|
$10.01 |
Good |
1% |
$0.10 |
Discount rounded down |
|
$50.01 |
Good |
1% |
$0.50 |
Discount rounded down |
|
$.01 |
Excellent |
1% |
$0.00 |
Discount rounded down |
|
$50.00 |
Excellent |
1% |
$0.50 |
|
|
$50.01 |
Excellent |
5% |
$2.50 |
Discount rounded down |
The script would go something like this:
- Log on as a customer who has the rating listed in the table.
- Start an order, and put items in it until the total is the specified amount in the Item Total column on the test.
- Check that the discount on the Order Summary screen matches Discount Amount in the table.
Then the test would be repeated five more times to cover all six cases. Either Tom or Debbie would do this once the discount feature and order features are implemented. This test should be run for all possible combinations. That would have been more difficult if there were more discount percentages for more customer types. There's another possible way to run these tests.
Test User Interface
To simplify executing the tests, Debbie could set up a user interface that connects to the discount calculation module in her code. This interface would be used only during testing. But having it would cut down on the work involved in showing that the percentage was correctly determined. The interface might be a command-line interface (CLI) or a graphical user interface (GUI). For example, a CLI might be this:
RunDiscountCalculatorTest <item_total> <customer_type>
And when it is run for each case, such as
RunDiscountCalculatorTest 10,00 Good
It would output the result
0
A GUI, such as what's shown in Figure 4.2, might be connected to the CLI.
)
Figure 4.2 User Interface for Testing
Regardless of whether it is a GUI or CLI, the user interface has penetrated into the system. It exposes a test point within the system that allows easier testing. Here's an analogy showing the differences between this method and Tom's original test script. Suppose you want to build a car that accelerates quickly. You know you need an engine that can increase its speed rapidly. If you could only check the engine operation as part of the car, you would need to put the engine in the car and then take the car on a test drive. If you had a test point for the engine speed inside the car, you could check how fast the engine sped up without driving the car. You could measure it in the garage. You'd save a lot of time in on-the-road testing if the engine wasn't working properly. That doesn't mean you don't need to test the engine on the road. But if the engine isn't working by itself, you don't run the road test until the engine passes its own tests.
If you're not into cars, Figure 4.3 shows a context diagram. The Order Summary screen connects to the system through the standard user interface layer. The Discount Percentage user interface connects to some module inside the system. Let's call that module the Discount Calculator. By having a connection to the inside, a tester can check whether the internal behavior by itself is correct.
)
Figure 4.3 Context Diagram
xUnit Test
The next way to perform the testing is to write the tests for the Discount Calculator in a unit testing framework. The framework used is usually in the language that the program is written in. There is a generic framework called xUnit that has versions for many programming languages. Here's a sample of what these tests look like in Java using Junit [Beck01]. The test would look similar in TestNG [Beust01], but the order of the parameters would be reversed:
class DiscountCalculatorTest {
@Test
public void shouldCalculateDiscountPercentageForCustomer() {
DiscountCalculator dc = new DiscountCalculator();
assertEquals(0, dc.computeDiscountPercentage(10.0,
Customer.Good));
assertEquals(1, dc.computeDiscountPercentage (10.01,
Customer.Good));
assertEquals(1, dc.computeDiscountPercentage (50.01,
Customer.Good));
assertEquals(1, dc.computeDiscountPercentage(.01,
Customer.Excellent));
assertEquals(1, dc.computeDiscountPercentage(50.0,
Customer.Excellent));
assertEquals(5, dc.computeDiscountPercentage(50.01,
Customer.Excellent));
}
}
Any time there is a change in the examples that Betty and the stakeholder use to explain the business rule, Debbie may want these tests to conform to the changed examples. That's a bit of waste. The next testing framework can eliminate that waste.
Automated Acceptance Test
Betty, Debbie, and Tom agreed that the examples in the table accurately reflected the requirements and there would be less waste if the table did not have to be converted into another form for testing. Several available acceptance test frameworks use tables. Some examples are in Appendix C, "Test Framework Examples." With these frameworks, you describe the tests with a table similar to the one for the example.
The following test table works in table-based frameworks, such as the FitNesse and Fit frameworks. A similar style table can be used in narrative-form frameworks, such as Cucumber.3 The table looks practically like the one that Betty presented to the stakeholder.
|
Discount Calculation |
||
|
Item Total |
Customer Rating |
Discount Percentage() |
|
$10.00 |
Good |
0% |
|
$10.01 |
Good |
1% |
|
$50.01 |
Good |
1% |
|
$.01 |
Excellent |
1% |
|
$50.00 |
Excellent |
1% |
|
$50.01 |
Excellent |
5% |
Now when the table is used as a test, the Fit/FitNesse framework executes code that connects to the Discount Calculator. It gives the Discount Calculator the values in Item Total and Customer Rating. The Discount Calculator returns the Discount Percentage. The framework compares the returned value to the value in the table. If it agrees, the column shows up in green. If it does not, it shows up in red. The colors cannot be seen in this black-and-white book. So light gray represents green and dark gray represents red. The first time the test was run, the following table was output.
|
Discount Calculation |
||
|
Item Total |
Customer Rating |
Discount Percentage() |
|
$10.00 |
Good |
0% |
|
$10.01 |
Good |
1% |
|
$50.01 |
Good |
Expected 1% Actual 5% |
|
$.01 |
Excellent |
1% |
|
$50.00 |
Excellent |
1% |
|
$50.01 |
Excellent |
5% |
With the results shown in the table, it was apparent there was an error in the Discount Calculator. Once it was fixed, Betty saw the passing tests as confirmation that the calculation was working as desired.
An Overall Test
If the discount test is applied using one of the last three forms, there still needs to be a test using the order interface. This ensures that processing an order is correctly connected to the Discount Calculator. The script for an order would be run for a couple of instances. But unless there was a large risk factor involved, the script might just be executed for a few cases, such as the following.
|
Discount Calculation |
|||
|
Item Total |
Customer Rating |
Discount Percentage? |
Discount Amount? |
|
$10.01 |
Good |
1% |
$0.10 |
|
$50.01 |
Excellent |
5% |
$2.50 |