Developing unit test specifications in software testing

Once a unit has been designed, the next development step is to design the unit tests. An important point here is that it is more rigorous to design the tests before the code is written. If the code was written first, it would be too tempting to test the software against what it is observed to do (which is not really testing at all), rather than against what it is specified to do. A unit test specification comprises a sequence of unit test cases. Each unit test case should include four essential elements:

  1. A statement of the initial state of the unit, the starting point of the test case (this is only applicable where a unit maintains state between calls);

2. The inputs to the unit, including the value of any external data read by the unit;§ What the test case actually tests, in terms of the functionality of the unit and the analysis used in the design of the test case (for example, which decisions within the unit are tested);

3. The expected outcome of the test case (the expected outcome of a test case should always be defined in the test specification, prior to test execution).

The following subsections of this paper provide a six step general process for developing a unit test specification as a set of individual unit test cases. For each step of the process, suitable test case design techniques are suggested. (Note that these are only suggestions. Individual circumstances may be better served by other test case design techniques).

Step 1 - Make it Run

The purpose of the first test case in any unit test specification should be to execute the unit under test in the simplest way possible. When the tests are actually executed, knowing that at least the first unit test will execute is a good confidence boost. If it will not execute, then it is preferable to have something as simple as possible as a starting point for debugging.

Suitable techniques:

  1. Specification derived tests

2. Equivalence partitioning

Step 2 - Positive Testing

Test cases should be designed to show that the unit under test does what it is supposed to do. The test designer should walk through the relevant specifications; each test case should test one or more statements of specification. Where more than one specification is involved, it is best to make the sequence of test cases correspond to the sequence of statements in the primary specification for the unit.

Suitable techniques:

- Specification derived tests

- Equivalence partitioning

- State-transition testing

related post

DAY 1 MICROSOFT DOT NET FRAME WORK

DAY 2 MICROSOFT DOT NET BASE CLASS LIBRARY

DAY 3 MICROSOFT DOT NET CLASSES AND STRECTURES

DAY 4 METHODS IN FRAME WORK

DAY 5 INPUT VALIDATIONS IN DOT NET PART ONE

DAY 6 INPUT VALIDATIONS IN DOT NET PART TWO

DAY 7 DATA TYPES IN DOT NET

DAY 8 DATA TYPES IN DOT NET PART TWO

DAY 9 IMPLEMENTING PROPERTIES IN DOT NET

DAY 10 DELEGATES AND EVENTS

DAY 11 OOPS INTRODUCTION

DAY 12 POLYMORPHISM

DAY 13 INHERITANCE AND POLYMORPHISM

DAY 14 EBUGGING TOOLS IN DOT NET

DAY 15 DEBUG AND TRACE IN CLASSES

DAY 16 UNIT TEST PLAN

DAY 17 EXCEPTIONS IN VISUAL STUDIO

DAY 19 ADO.NET INTRODUCTION

DAY 20 DATA ACCESSING IN DOT NET

DAY 21 DATA BASE OBJECTS

No comments:

Post a Comment