Chapter 16. Developer Acceptance Tests

“What is good for the goose is good for the gander.”

Anonymous

The triad has developed acceptance tests for stories that Cathy created. When a developer needs a component from another developer, the requester should create acceptance tests for that component.

Component Acceptance Tests

Acceptance tests are not generated by just the customer unit. Many software development organizations have groups that develop common modules or components for other groups. The requesting group needs to supply acceptance tests for those modules.

Field Display Tests

For example, specialized developers often create custom user interface components. User interface developers use these components in web pages. Let’s look at a couple of common components. One is a text box that accepts a formatted string, such as a phone number or an e-mail address. The other is a tabular style–component that allows sorting by the values in columns. The tests may look like specifications or vice versa.

Cathy wants a field on the display for entering a phone number. Obviously, you should check the data entered into the field for validity. The format differs between nations; so to keep it simple, the example shows a U.S. phone number. The N in the table means a number or a digit.

Here are some of the tests Debbie might create for a U.S. phone number field.¹

Suppose Don is the developer who is going to create this component. The first thing Debbie needs to do is give an acceptance test for what it should look like. For example, will it display the dashes immediately or as a person types the digits? Let’s suppose the former. Debbie creates an image of what the component should look like in Figure 16.1. The image is part of the acceptance test, but one you have to verify manually. You also need to check the color and font.²

Figure 16.1. State Diagram

Debbie also needs to specify to Don what should occur if the phone number is incorrectly formatted. Should the component just return a failure code? Or should the component produce an output as a beep or error message? Since the phone number box will be used repeatedly on every form that requires one, this decision may need to be made by a corporate user interface standards group. Suppose Cathy wants the error to be displayed when the user finishes an entry in the field. So Debbie constructs a table that describes how the error should appear.

Debbie needs to show Don what component should be output when the value is submitted. This table shows that the dashes should be included in the output value. Another possibility is that the dashes should be eliminated.

Don creates a form with a Phone Number field on it and a Submit button. He then demonstrates to Debbie that the component passes the tests for both a valid and an invalid entry. Next, he shows that the field sends the correct information when the Submit button is pressed. He also devises a form with three entry fields—one prior to the Phone Number field and one after it—and a Submit button. He demonstrates that the field works with other entry fields by allowing the user to tab to the next and previous entries.

This component is a user interface component, so there will be some manual tests to ensure that it is acceptable to a human being. You can create automated tests to check that the component continues to work even if you change its underlying implementation.

Tabular Display Tests

Here’s a display component that is more complicated. A user interface often contains a table of items. The table component might allow the user to sort the table by the values in each column, or it may have links within the table. Cathy or Debbie needs to determine what should be displayed if there are no values in the data to be shown in the table and what to do if the number of values is large.

Here are some potential inputs to a table display. It doesn’t matter whether these values come from a program component, such as a Java class, or a database query. That’s a matter of connecting up the table to the appropriate code. The first input is a simple set of data.

Debbie needs to show Don how this data should appear on the screen. Suppose that Cathy wants to have shaded column heads and shading on every other row (see Figure 16.2). The output specification is concerned only with appearance, not how the display is generated.³

Figure 16.2. Table Display

Debbie and Don need to clarify the contract for the table display component. Should it be Debbie’s job to ensure that the component never gets passed an empty table or a really big table, or should it be the component’s responsibility to handle these cases? If the latter, Debbie needs to create some tests for these two conditions.

She also creates tests for a larger number. Suppose the table should only display 20 rows at a time. There would be a test that shows what happens if there are more rows to display. For example:

Tom might come up with a few more tests. He might want to see what happens if there are exactly 40 or some large number such as 10,000,000. Debbie and Don might then decide that the component does not need to handle more than a reasonable number of components, such as 1,000.

Instead of the buttons at the bottom to see the other items, the table could display 20 items but have a scrollbar if there are more. There would then be a test that provided 1,000 items of data to see how fast the component could scroll.

The table data might have links associated with it. Suppose that clicking on the name was supposed to go to a particular page associated with the data. The links would be in the supplied data, and the test would look like this.

The table might offer a sorting feature. When the user clicks on a column header, the rows should be sorted by the values in that column. Debbie gives tests to Don to demonstrate what she means. The tests could include more rows than fit on the screen to show that sorting is on the entire set of data, not just the rows displayed on the screen. With just a few rows, here’s a test for the Date column.

There are a lot of other considerations in the sorting. For example, what if two values match? Which should come first? Or if the user clicks a second time on a column header, should it reverse the sort?⁴

Summary

• Developers should supply acceptance tests for components created by other developers.

• Acceptance tests for display components should include combinations of inputs that result in different display appearance or response.

• Acceptance tests for user interface components may be manual.