class testing software engineering of standalone programs university of colorado, boulder

Class Testing

Software Engineering of Standalone Programs

University of Colorado, Boulder

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing

2

Overview Class Testing Testing Interactions between objects Testing Class Hierarchies


3

Basics – How to test a single class

Class Testing How to Test a Class Aspects of Class Testing How to Construct Test Cases When is a class test suite adequate? How to Construct a Test Driver

Testing Interactions between objects Testing Class Hierarchies


4

Definition of class testing Verifying implementation of a class = verifying the

specification for that class

If so, each of the instances should behave properly.

Assumption: The class in question has a complete and

correct specification that has been tested earlier in the context of models

Spec is expressed in natural language or as a state transition diagram


5

Ways to test a class Code can be tested effectively by

inspection (preferable when construction of a test driver is too difficult)

execution of test cases (lends itself to easy regression testing later on)

Remember: When you test a class, you are really: creating instances of that class and testing the behavior of those instances.


6

Aspects of Class Testing

Decide test independently test as a component of a larger part of the

system How decide – combination of the following:

Role of the class in the system – degree of risk Complexity of the class Amount of effort associated with developing a

test driver Sometimes, needs so many collaborators,

makes more sense to test in a cluster


7

Who Tests? How much?

Who – class usually tested by its developer Understands class’ spec Familiar with the code Test driver can be used by the developer to

debug code while writing it but ... perpetuates misunderstanding – needs

inspection at model stage to head that off What – ensure that the code for a class exactly

meets the requirements – no more, no less


8

When are tests written?

When – A test plan that identifies test cases should be developed soon after a class is fully specified and ready for coding. Especially if developer is the class tester Why?

(What’s the danger in developer alone writing and reviewing test cases for the class?)

When again? Iterative development – the driver and the test

cases will be available to supplement or change as the class is enhanced or modified


9

How can you test “just a class”?

How – Create a test driver that

creates instances of the class sets up a suitable environment around those

instances to run a test case sends one or more messages to an instance

as specified by a test case checks the outcome based on a reply value,

changes to the instance, or parameters to the message

deletes any instances it creates if responsible for storage allocation


10

How do we test static data in a class?

How – continued: Static data members or operations

testing required they belong to the class itself rather than to

each instance of the class the class can be treated as an object

If the behavior of the instances of a class is based on the values of class-level attributes test cases for testing the class-level attributes

must be considered as an extension of the state of the instances


11

How MUCH testing is done at this level?

How much – Adequacy of testing measured in terms of how much of the specification has been tested how much of the implementation has been

tested Want to test operations and state transitions in

many combinations Objects maintain state. “State” affects the

meaning of operations.


12

Constructing test cases - identification

Identification of test cases Should be made from the specification that has

been reviewed rather than from the implementation which may embody developer’s misunderstandings

Best: develop from spec and augment to test boundaries introduced by the implementation

If no spec exists: create one from the code and verify it with the developer


13

Constructing test cases – identification2

Identify requirements for test cases for all possible combinations of situations in which a precondition can hold post conditions can be achieved

Create test cases for those requirements specific input values – typical and boundary determine correct outputs eliminate conditions that are not meaningful

Add test cases to show what happens when a precondition is violated


14

Constructing Test Cases – from STD’s State Transition Diagrams

They show behavior associated with instances of a class

Each transition represents a requirement for one or more test cases


15

Constructing test cases from STD’s 2

Suppose 6 transitions between states Plus 1 constructor and 2 destructors That makes 9 requirements

Select representative values Select boundary values on each side of a

transition If the transition is guarded, select boundary

values for the guard condition Boundary values are based on the range of

attribute values associated with a state


16

Top-level Statechart for Elevator Control


17

Adequacy of a Class Test Suite Ideally – exhaustively test each class Practically – impossible or too hard Worth it to exhaustively test some classes with

high risk Measures of adequacy to increase confidence that

we have tested enough state-based coverage constraint-based coverage

Constraints are pre and post conditions and the class invariant

code-based coverage


18

State-based coverage How many of the transitions in a state transition diagram

are covered by the test suite? “Covered” = touched at least once May reveal each transition was covered but test values

do not adequately cover value ranges If test cases were generated correctly from a state

transition diagram with typical values and good boundary values, the test cases will achieve adequate state-based coverage

If test cases were generated from pre- and post conditions, then it is useful to check them against the state transition diagram to ensure each transition is covered.


19

State-based coverage: object interaction Note how operations interact w.r.t. transitions

Current State

Input or event

Action Output Next State

Sa E1 O1 Sc

Sb E2 O2 Sc

Sc E3 Sd

Test cases for the transition from Sc to Sd may work if Sc was reached from Sa but not if Sc was reached from Sb. “State” is a function of history.


20

State-based coverage: transition pairs Concerning problem on previous page:

Check that the test cases cover all pairs of transitions in the state transition diagram.

In previous table, create test cases to test: SaSc and ScSd SbSc and ScSd


21

Statechart for Elevator Control


22

Hierarchical statechart for Elevator Control


23

Portion enlarged


24

Constraint-based coverage How many pairs of pre- and post conditions have

been covered? Using the technique described earlier for

generating test cases from pre and post conditions, if one test case is generated to satisfy each requirement, then the test suite meets this measure


25

Constraint-Based coverage: object interaction

For each operation opn that is not an accessor operation, identify the operations op1, op2, etc. for which

their preconditions are met when the post conditions for opn hold.

That is, post condition(opn) satisfies (>=) precondition(op1), etc.

Then execute test cases for operation sequences opn-op1, opn-op2, etc.


26

Class Diagram

Elevator Elevator Doors

Timer

Elevator Button

Up Floor Button

Floor

1 1 1 1

1

11

11

m

0…n

0…n

Travels-to

Travels-from

Opens-Closes Controls

Controls

Contains

velocity: ±m/sposition: meters

floor: integeron: Boolean

open: Booleanclosed: Booleanjammed: Boolean

time: seconds

floor: integerposition: meterson: Boolean

Down Floor Button

1

1

Contains

on: Boolean

Light

1on: Boolean

1

Turns-on

1

Turns-on 1Turns-on

1

1

Elevator Controller

1

0…n

ControlsRequests-elevator-of

Indicates-arrival-to


27

How do we complete the class test? States do not correspond 1-1 to methods or to

classes so the state transition diagram gives a different perspective

We want to adequately test the class Test each state transition, better yet, the pairs Look at the class diagram and see which classes

send messages to it To create a driver to simulate each class

sending msgs to the class-under-test could be difficult

If you only test each association in this application, it may be a weak level of testing for that class


28

Constraint coverage completes testing it

If you test class A calling every msg it can in class B, that’s more coverage but …

If you use existing classes to do that, it’s hard to get the right combination set up to make it happen

Alternative: Write a driver with sequences of messages to

access sequences of methods in the class you are testing.


29

Which sequences??

Look at the post conditions of each method in the class you want to test

Look at preconditions of each Find sequences where

the Post(m1) >= pre(m2) the Post(m2) >= pre(m3) Send msgs to m1; m2; m3

Do this for all possible combinations


30

Completion check

See which associations were tested by comparing to the class diagram

See which state transitions were covered this way If some state transitions were missed or if some

post/pre condition pairs or associations were missed, add a few tests


31

Where do the pre and post conditions come from?

Use cases?? The methods themselves? The class invariant?

class testing software engineering of standalone programs university of colorado, boulder

Documents