Test data tables

A test data table allows you to define test input and expected output data that can be used when you run a test. Test data tables are synchronized with the test behavior script, so modifications that you make to the code are reflected in the test data table and vice versa.

Because each test data table maps to a particular test case (a JUnit test method) in your test code, a separate test data table is created for each test method. As you work with the test behavior code, the test data table view is automatically updated when you move the cursor from one cell to another. When you first open your test behavior code, no test data table is displayed until you move the cursor to a test method in the code.
Note: For the test data table and test behavior script to synchronize as expected, make sure that the Project > Build Automatically option is enabled. Click Save button Save to force the synchronization.

The following screen capture shows an example of a test data table.Illustration of a Test Data Table

Each row in the test data table represents an object or expression in your code, and each column represents a data set (or equivalence class). Each data set column is divided in half, one half for the input values, and the other half for the expected output values. Expected outputs include return values, exceptions, and any parameters that are specifically marked for output.

The test data table provides content assist which automatically completes content on certain cells when you press Ctrl+Space. It also automatically validates syntax and data type to guarantee that the data you enter is syntactically correct.
Note: Syntax validation is turned off automatically if a test cannot compile.

With test data tables you can perform the following tasks:

Supplying test data in the form of expressions, sets, ranges and datapools

Any syntactically valid expression that can appear on the right side of an assignment statement can be entered as an expression in the test data table. This includes primitives, strings (enclosed in double quotes), variable references, and constructor and method calls.

You can also insert sets and ranges to be used as test input, expected outputs, and return values. The test data table contains its own set and range editors for defining sets and ranges. Simply right-click in a table cell and click Define Set or Define Range. Note that you cannot enter a set or range within the cell without using the set or range editors. A set is shown in a data table by curly braces ({ }) and by as many comma-separated values as required to define the set. A range is shown in a data table by comma-separated values enclosed within square brackets ([ ])

Your test data tables can also include links to datapools. A datapool is a collection of related data records comprised of primitive data types or their corresponding wrapper types Each variable in the datapool is interpreted as a set by the test data table. You can edit the datapool with the Datapool Editor, which you can open by double-clicking the datapool link.

Adding elements to an array

In addition to using expressions, ranges, sets, and objects in test data tables, you can also use arrays. An arrays is a container for an ordered list of primitive or object elements. Arrays can be one-dimensional or multi-dimensional; that is, they can contain other arrays. Arrays are displayed hierarchically in the test data table with each element in the array appearing in its own row, nested beneath the row that represents the array. Each element in the array is displayed with its index and can be retrieved and changed independently. Thus, the first element in an array is displayed as [0], the second element is displayed as [1], and so on.

Supplying test data for the attributes of object data types

Arguments that are based on primitive types (int, char, double, long, and so on), wrapped primitive types (such as Integer or Double), or Strings can be visualized as a single row in a test data table. However, objects with multiple defining attributes cannot be visualized in a single row in the test data table. These complex objects are represented hierarchically in several rows of the test data table.

When you click in the test data table in any cell that contains an object, you can select from a list of ways to define the object. Objects can be defined according to one or more constructors or one or more sets of object properties. When you choose an item from the list, the row representing the object expands to display the defining attributes that you have chosen.

Partitioning your data into data sets

A data set (or equivalence class) is a set of input values that are all expected to invoke the same behavior. Data sets help you partition your data into logical units that should be handled the same way by your code. Each data set in a test data table contains one column for the input values and another column for the expected output values.

Each data set provides values for one or more test runs. If there are three data sets in the test data table, the same test behavior will be executed at least three times. (If sets and ranges are used as values in the test data table, there will be a test run for each value in the set or range.)

Using a subclass to initialize and test an object

Test data tables contain a type column that can be edited so that variables of an interface type or a type with inherited classes can have data that is of the implementing class or subclass. For example, take a hypothetical method named drawCalendar that takes a single argument of type Calendar, which in turn has GregorianCalendar and LunarCalendar as subclasses. If you want to define a set of tests that pass an object of type GregorianCalendar, you would edit the type field for the argument. When you edit the type, the original argument type is displayed in the method signature.

Specifying breakpoints in data sets

When you are debugging your tests, it can be useful to define breakpoints in the test data table. When you run the test in debug mode, a breakpoint causes the execution of a program to be suspended at the location where the breakpoint is set. There are three places where breakpoints can be set in a test:
  • In the left ruler of the Java editor: This suspends the execution at the corresponding line in the test behavior script.
  • In the left ruler of the test data table. This suspends the execution when the corresponding action is encountered.
  • In the data set header of the test data table: This suspends the execution when the corresponding data set is encountered.
To set a breakpoint, double-click the corresponding ruler or location, or right-click and select Toggle breakpoint in the context menu.
Related concepts
Data sets
Data partitioning techniques
Expressions
Test-generation process
Stub data tables
Related tasks
Defining sets
Defining ranges
Adding elements to an array
Linking to a datapool
Supplying test data for the attributes of object data types
Using a subclass to initialize and test an object
Selecting an expected exception
Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.