Copyright © 1999 Sita Ramakrishnan, Monash University All rights reserved

Light Views

HomeCase StudiesOO TheoryHelp

Light Views Icon

Case Studies

Introduction

Component Testing
Specifying Components
Component Testing of Methods
Testing Primitive Classes
Statebased Testing

Deriving Structural and Interaction Test Cases

Testing distributed architectures

State based testing
Player TicTacToe Game

Event based testing of JavaBean

Parallel Architecture for Component Testing

Quiz

Questionnaire

TicTacToe Game

Component Testing

There are two aspects to component testing:

  1. Does it meets its specification and fulfill its functional requirements?
  2. Does the correct and complete structural and interaction requirement reflected in the implementation software system?

Specifying Components

A class has two levels of specification: method level that contains the pre and postcondition requirements for each method of a class; and component level where a class invariant is specified which must hold for all methods as well.

Class level specification uses a state machine to specify temporal constraints on the interactions among its methods.

Component testing of methods

An adequate test criteria for testing a method specification:

  • check every OR clause in every postcondition activated by at least one test case.
  • every precondition is violated by at least one test case.
  • every method must satisfy the class invariant.
  • implement a test method that explicitly checks the class invariant.
  • call this method during each test case.

Testing "Primitive" Classes

John McGregor defines classes which depend either only on primitives in the programming language or on classes that have been tested and trusted as Primitive classes.

  • examine the methods & look at their signature, pre & postcondition
  • parameters and return types of methods (for building testcases)
  • for boolean return types, have 2 test cases to cover true/false
  • precondition has information needed to check that the answer returned from is correct. So,
    • design inputs to set up a specific test case
    • apply the test
    • check that the result obtained matches what was expected

State Based Testing

  • errors in a state machine - omission of a state or transition
    • - test suite can detect this error by checking thoroughly for all the states and transitions, e.g. by comparing it to other model diagrams
  • incorrect output from a transition - check against expected result or postcondition

Selecting Test cases

  • State based test cases are selected to cover the state model.
  • The levels of coverage could be - all states visited, all methods exercised, all transitions exercised, and so on.

 

Funded by Committee of University Teaching And Staff Development (CUTSD) through DEETYA, 1998