Stub behavior
Stubs are classes that provide replacement implementations for the actual classes called by your code. Stubs can be generated for Java components, for Enterprise JavaBeans (EJB), and for Web services.
Stubs are typically used for the following purposes:
- To isolate the testing of the component-under-test (CUT) from other classes or components that the CUT interacts with
- To implement unavailable classes or components that the CUT needs to interact with
- To verify the interactions of the CUT with external components
- To verify the behavior of the CUT when one of its service providers generates exceptions or atypical values
You can define a stub of a Java class and reuse that stub in multiple tests. Once you create the stub, you define its behavior in the stub data table or you enter code in the user code class that is associated with the stub.
Stub data tables
Stub data tables define the output behavior of a stubbed class in response to certain inputs. With the stub data table, you simulate the stubbed class by specifying the actual input and return values for each stubbed method. The use of the stub data table is demonstrated in the following sample real estate application.
In this application, there are two classes being tested: Lender and Appraiser. A third class named Mortgage is stubbed to more easily isolate the testing of the Lender and Appraiser classes. These classes and their methods are summarized in the following table:
| Lender | Appraiser | Mortgage |
|---|---|---|
| validateCredit | getBestMortgageRate | getAPR |
| computeFixed30y | ||
| computeARM30y |
The getAPR method in the Mortgage class takes two input parameters, points and score, and returns the rate. As shown in the following figure of the stub data table for the Mortgage class, if the points parameter is equal to 1, regardless of the score parameter, the rate output is 5.94%. If the points parameter is equal to 2, and the score is in the range of 700 to 900, the rate output is 5.69%.
Through the use of the stub data table, you can simulate how the getAPR method behaves.
Note: If you have overlapping input values, the behavior defined in the data set on the left takes precedence. For example, if the first data set contains a range of 1 to 20, and the second data set contains a range of 1 to 10, the stub returns the specified values from the first data set for 1-20 and ignores the values in the second data set.
The stub user code class
Another way to define stub behavior is to add code to the user code class that is generated along with the stub. Typically, you define stub behavior in the user code class in cases where the behavior cannot be performed in the stub data table. For example, you might do this in the following cases:
- You need to perform tasks to set the external state so tests can be executed in the proper context.
- A method needs to perform a function that is not data related, such as creating a file.
- The values to be returned cannot be defined in the stub data table because the values on an external file or database.
- You need to specify stub behavior based on conditions other than the input values.
Any code that you add to the user code class for a particular method takes precedence over the behavior specified in the stub data table.
Stubs with Enterprise JavaBeans (EJBs)
It is also possible to use stubs when testing session beans. For example, you might want to stub a session bean whose business methods are not yet fully implemented. In most cases, it is not necessary to stub entity beans because you can test entity beans in isolation without using stubs.
Related concepts
Stub data tablesComponent testing and the Java editor
Related tasks
Creating stubs for Java componentsCreating stubs for session beans
Editing stubs in a test suite
Inserting initialization points
Inserting validation actions
Inserting timing constraints