This question appears in Mumbai University > Software Testing & Quality Assurance Subject

Marks: 10 M

Year: Dec 2011, June2012

Dynamic Unit Testing :

• Execution based unit testing is referred to as dynamic unit testing. In this testing, a program unit is actually executed in isolation. However, this execution differs from ordinary execution in the following way:

1. A unit under test is taken out of its actual execution environment.

   1. The actual execution environment is emulated by writing more code so that the unit and the emulated environment can be compiled together.

   2. The above compiled aggregate is executed with selected inputs. The outcome of such an execution is collected in a variety of ways, such as straightforward observation on the screen, logging on files, and software instrumentation of the code to reveal run time behaviour. The result is compared with the expected outcome.

Dynamic Unit Testing environment:

• An environment for dynamic unit testing is created by evaluating the context of the unit under test, as shown in the above figure.

• The context of a unit test consists of two parts : (a) a caller of the unit and (b) all the units called by the unit.

• The caller unit is known as a test driver, and all the emulations of the units called by the unit under test are called stubs. The test driver and the stubs are together called scaffolding.

• The functions of a test driver and a stub are as follows:

1. Test Driver :

• A test driver is a program that invokes the unit under test. The unit under test executes with input values received from the driver and, upon termination, returns a value to the driver.

• The driver compares the actual outcome, that is, the actual value returned by the unit under test, with the expected outcome from the unit.

• The test driver functions as the main unit in the execution process.

• The driver not only facilitates compilation, but also provides input data to the unit under test in the expected format.

2. Stubs:

• A stub is a “dummy subprogram” that replaces a unit that is called by the unit under test.

• Stubs replace the units called by the unit under test.

• A stub performs two tasks. First, it shows an evidence that the stub was, in fact, called. Such evidence can be shown by merely printing a message. Second, the stub returns a precomputed value to the caller so that the unit under test can continue its execution.

• The test driver and stubs are tightly coupled with the unit under test and should accompany the unit throughout its life cycle.

• The driver and the stubs are never discarded after the unit test is completed. Instead, those are reused in the future in regression testing of the unit if there is such a need.

• The test driver should not depend on the external input data files but, instead, should have its own segregated set of input data.

• The test driver should have the capability to automatically determine the success or failure of the unit under test for each input data.

• A test driver and the stubs for a unit should be reusable and maintainable.

• Finally, the test driver and stubs should be reviewed, cross-referenced with the unit for which these are written, and checked in to the version control system as a product along with the unit.

• Hence, the environment of dynamic unit testing is emulated because the unit is to be tested in isolation and the emulating environment must be a simple one so that any fault found as a result of running the unit can be solely attributed to the unit under test.