Unit testing is normally considered as an adjunct to the coding step. After source-level code has been developed, reviewed, and verified for correct syntax, unit test case design begins. A review of design information provides guidance for establishing test cases that are likely to uncover errors in each of the categories discussed above.
Each test case should be coupled with a set of expected results.Because a module is not a standalone program, driver and or stub software must be developed for each unit test. The unit test environment is illustrated in figure 5.6.In most applications a driver is nothing more than a "Main program" that accepts test case data, passes such data to the test module and prints relevant results.
Stubs serve to replace modules that are subordinate to the module that is to be tested. A stub or "dummy sub program" uses the subordinate module's interface may do minimal data manipulation prints verification of entry, and returns.
Drivers and stubs represent overhead. That is, both are software that must be developed but that is not delivered with the final software product. If drivers and stubs are kept simple, actual overhead is relatively low. Unfortunately, many modules cannot be adequately unit tested with "simple" overhead software.In such cases, Complete testing can be postponed until the integration test step (Where drivers or stubs are also used).Unit test is simplified when a module with high cohesion is designed. When a module addresses only one function, the number of test cases is reduced and errors can be more easily predicted and uncovered.
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
QUALITY ASSURANCE PART TWO
QUALITY ASSURANCE SQA
QUALITY OF DESIGN OF TEST CASE
QUALITY MANAGEMENT IN SOFTWARE TESTING
TOOLS FOR QUALITY MANAGEMENT
STATICAL QUALITY ASSURANCE
ISO APPROACH TO QUALITY TESTING