Stunt Driver Interface

Intent

Provide a mechanism for plugging any component into a generic black box test framework.

Problem

Testing is important, no question. Black box testing is a great way to validate a set of results against a given set of inputs. With a good test environment, black box testing can also be used to compare the speed of various implementations , do regression testing, perform stress/load testing, perform boundary value testing, etc. Typically, though, each component tends to need its own test scaffold , which makes it difficult to justify spending the time to build an environment that provides the functionality allowing for all the testing we would like to do.

This pattern is intended to allow a specific interface to be defined so that any class implementing can easily be plugged into an existing test framework, eliminating the need to rebuild each time.

Forces

The Stunt Driver interface (Figure 3.13) can be implemented for any class you want to test that:

• Has input(s) you can specify

• Has result(s) you want to review

Figure 3.13. Stunt Driver pattern structure.

Structure

Consequences

The Stunt Driver interface has the following benefits and liabilities:

1. It provides generic testability by implementing only two methods . By defining the data types of the parameters needed to test the component (GetTestParameters) and a Test function that accepts the list of parameters (Test), any component can be plugged into a standard interface.

2. It provides a place to store the default test case . Even if the interface does not want to implement a method for storing a set of test values for testing the component, the GetTestSet provides a method for returning a number of test cases.

Participants

• ITestable component ”Any component that needs to be tested

• Test Client ”Client that provides the ability to load testable components , build test cases, store results, rerun for comparisons, etc.

Implementation

A number of simple implementations are included in the Calc and Factors project. I will describe the implementation of the Factors.Factor class, which adds the ITestable interface to the Factor class used for the threading patterns. This will be compared against the Calc.Add class, which takes multiple parameters.

The first method necessary is GetTestParameters. In my implementation, I am using the sorted list collection for the simplest implementation. This could easily be replaced with any collection, including a dataset or abstract packet, as appropriate. The Factor class needs only the input value to be factored so one item is added to the collection, indicating the name and type needed.

Listing 3.15 Getting the test parameters from the Stunt Driver.

 public System.Collections.SortedList GetTestParameters()       {          System.Collections.SortedList list = new System.Collections.SortedList();          list.Add("Value", typeof(System.UInt64));          return list;       } 

It is assumed that the client will use this collection to provide an interface that allows individual test cases to be entered. The TestBed application provides a sample of one such interface behind the Test Case button (Figure 3.14) that creates a data table based on the result and allows the user to enter any number of rows, each having the values requested . In this case, each row would have one value that is a 64-bit integer.

Figure 3.14. Configuring the Stunt Driver with the Test Bed sample interface.

To be honest, most of the time I don't want to have to input or remember the best test cases, so I created the GetTestSet method to speed the generation of test cases. In the case of the Factor class, the test sets generated are based on a set of random numbers to be factored. Again, this method uses the SortedList for simplicity implementation, but any appropriate collection could be used.

Listing 3.16 Building a test set the easy way with the Stunt Driver.

 public System.Collections.SortedList[] GetTestSet( int Count)    {       System.Collections.SortedList[] alist = new System.Collections.SortedList[Count];       for (int i=0; i < Count; i++)       {          alist[i] = new System.Collections.SortedList();          alist[i].Add("Value", r.Next());       }       return alist;    } 

Finally, to perform the actual test, the class must simply pull the value from the input parameter list and pass this to the method that does the actual work. Here, the class has the ability to pass back any result information desired by simply adding it to the parameter list.

Listing 3.17 Testing with the Stunt Driver.

 public bool Test( ref System.Collections.SortedList Parameters)    {       System.UInt64 val = UInt64.Parse(Parameters["Value"].ToString());       Parameters.Add("Result", Factorer.Factor(val));       return true;    } 

When dealing with more than one parameter as the input, it is just a matter of adding additional items to the test parameter list returned by the first method. For example, the Calc.Add class takes two values, so the GetTestParameters function would look like Listing 3.18:

Listing 3.18 Adding items to the test parameters.

 public System.Collections.SortedList GetTestParameters()    {       System.Collections.SortedList list = new System.Collections.SortedList();       list.Add("Value1", typeof(int));       list.Add("Value2", typeof(int));       return list;    } 

Each of the other methods needs only to retrieve or set the additional value.

Related Patterns

• Dynamic Assembly Loader (Eshelman)