• Branch coverage - need to test both branches of an if-then-else - note - branch testing does not cover complete test specification. Do not turn in components which are only branch tested
• Statement coverage
• Condition coverage - cover all branches & all compound conditions (e..g loops, array handling) within the branch are exercised at least once as well.
• Path coverage - don't restrict to branches, do all combination of tests - cover edges with branch testing. More things looked at here than branch testing, but does not guarantee about input values etc. But, path coverage may lead to infinite number of paths in programs with loops. Use loop coverage to augment branch coverage by executing every branch, plus executing loops to cover every executable path - attempt to test loop bounds, loop zero times, max. & avg. no. of times .
• Using probes - instrument the code & get coverage test

Unit & Integration testing

• Strict unit testing & integration testing - use stubs & drivers to ensure that each module is unit tested independently of the rest of the system
• Elided unit testing & integration testing - test each module first in the context of the partially integrated system. Unit testing is not done as a separate activity. Avoid writing stubs as much as possible. Stub writing can be viewed as a waste of time in the context of cost/benefit analysis. Build & test incrementally. Prototyping approach can be viewed as testing the requirement incrementally.
• Breadth-first vs depth-first class development- selection impacts on testing.
• Breadth-first - develop the class interface with stubs for method implementation. Provide each stub with the actual method body, testing as each method implementation is provided.
• Require more regression testing if you follow this approach. One has to revisit and test the extended bits as well as check the original functionalities still work.

Test Plan first, then test scripts

Test scripts to contain a sequence of test cases. A test case in Hoffman et al's format where: - trace - a sequence of messages. <trace, expexc, actval, expval, type >

• expexc - name of exception that trace is expected to generate - noexc if no exception is expected
• dc - don't care
• actval - an expression, typically a function call (e.g inserting on a stack - Top function), to be evaluated after the trace. actval is taken as the actual value of the trace. - expval - expected value of actval
• expval - expected value of actval
• type - data type of actval & expval (dc to indicate don't care)

Selecting sequences of methods to test in a class

Test constructor(s) followed by various combinations of modifiers (mutator methods) & observers (accessors, displays).

Component Diagram

Demonstration: VCR Component Beans (applet)

We illustrate integration testing by showing the 3 bean components and the list of classes in each bean on a scrollable area on the screen with text underneath in a textfield.

From the 3 Beans (fig. 13) , clickable to classes in a Bean Class diagram shown with text box below. Hot areas to inherited & associated classes Click to get to blown up fig. of each class (again with relevant text in text box underneath the fig.) Hot areas of methods to generate test data - list of these to make up the test suite

The important things that we want to illustrate in detail re: structural testing are : test scripts & selecting test sequences in a class.

Integration tests use component diagrams. Component diagram in UML is an implementation diagram that shows the granular components such as JavaBeans or ActiveX components, used in the implementation. We implemented the VCR /TV operation as shown in the state diagram (see fig 9,) as a prototype Java Beans.

Fig 13. Java Bean Components Diagram for VCR System