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:
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:
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 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