while the code is being developed. In such cases, an emulator of the environment is useful in testing and debugging the code. Other kinds of tools that facilitate effective unit testing are as follows:
1. Code Auditor: This tool is used to check the quality of software to ensure that it meets some minimum coding standards. It detects violations of program- ming, naming, and style guidelines. It can identify portions of code that cannot be ported between different operating systems and processors. Moreover, it can suggest improvements to the structure and style of the source code. In addition, it counts the number of LOC which can be used to measure productivity, that is, LOC produced per unit time, and calculate defect density, that is, number of defects per KLOC.
2. Bound Checker: This tool can check for accidental writes into the instruc- tion areas of memory or to any other memory location outside the data storage area of the application. This fills unused memory space with a signature pattern (dis- tinct binary pattern) as a way of determining at a later time whether any of this memory space has been overwritten. The tool can issue diagnostic messages when boundary violations on data items occur. It can detect violation of the bound- aries of array, for example, when the array index or pointer is outside its allowed range. For example, if an arrayz is declared to have a range fromz[0] to z[99], it can detect reads and writes outside this range of storage, for example, z[−3] or z[10].
3. Documenters: These tools read source code and automatically generate descriptions and caller/callee tree diagram or data model from the source code.
4. Interactive Debuggers: These tools assist software developers in imple- menting different debugging approaches discussed in this chapter. These tools should have the trace-back and breakpoint capabilities to enable the programmers to understand the dynamics of program execution and to identify problem areas in the code. Breakpoint debuggers are based on deductive logic. Breakpoints are placed according to a heuristic analysis of code [32]. Another popular kind of debugger is known as omniscient debugger (ODB), in which there is no deduction. It simply follows the trail of “bad” values back to their source —no “guessing” where to put the breakpoints. An ODB is like “the snake in the grass,” that is, if you see a snake in the grass and you pull its tail, sooner or later you get to its head. In contrast, breakpoint debuggers suffer from the “lizard in the grass” problem, that is, when you see the lizard and grab its tail, the lizard breaks off its tail and gets away [33]. 5. In-Circuit Emulators: An in-circuit emulator, commonly known as ICE, is an invaluable software development tool in embedded system design. It provides a high-speed Ethernet connection between a host debugger and a target micropro- cessor, enabling developers to perform common source-level debugging activities, such as watching memory and controlling large numbers of registers, in a matter of seconds. It is vital for board bring-up, solving complex problems, and manu- facturing or testing of products. Many emulators have advanced features, such as
performance analysis, coverage analysis, buffering of traces, and advance trigger and breakpoint possibilities.
6. Memory Leak Detectors: These tools test the allocation of memory to an application which requests for memory, but fails to deallocate. These detect the following overflow problems in application programs:
• Illegal read, that is, accesses to memory which is not allocated to the application or which the application is not authorized to access.
• Reads memory which has not been initialized.
• Dynamic memory overwrites to a memory location that has not been allo- cated to the application.
• Reading from a memory location not allocated, or not initialized, prior to the read operation.
The tools watch the heap, keep track of heap allocations to applications, and detect memory leaks. The tools also build profiles of memory use, for example, which line-of-code source instruction accesses a particular memory address.
7. Static Code (Path) Analyzer: These tools identify paths to test, based on the structure of the code such as McCabe’s cyclomatic complexity measure (Table 3.3). Such tools are dependent on source language and require the source code to be recompiled with the tool. These tools can be used to improve produc- tivity, resource management, quality, and predictability by providing complexity measurement metrics.
8. Software Inspection Support: Tools can help schedule group inspections. These can also provide status of items reviewed and follow-up actions and distribute the reports of problem resolution. They can be integrated with other tools, such as static code analyzers.
9. Test Coverage Analyzer: These tools measure internal test coverage, often expressed in terms of the control structure of the test object, and report the cover- age metric. Coverage analyzers track and report what paths were exercised during dynamic unit testing. Test coverage analyzers are powerful tools that increase con- fidence in product quality by assuring that tests cover all of the structural parts of a unit or a program. An important aspect in test coverage analysis is to identify parts of source code that were never touched by any dynamic unit test. Feedback from the coverage reports to the source code makes it easier to design new unit test cases to cover the specific untested paths.
10. Test Data Generator: These tools assist programmers in selecting test data that cause a program to behave in a desired manner. Test data generators can offer several capabilities beyond the basics of data generation:
• They have generate a large number of variations of a desired data set based on a description of the characteristics which has been fed into the tool. • They can generate test input data from source code.
• They can generate equivalence classes and values close to the boundaries. • They can calculate the desired extent of boundary value testing.
3.9 TOOLS FOR UNIT TESTING 79