TOOLS FOR UNIT TESTING

3.9 TOOLS FOR UNIT TESTING

Programmers can benefit from using tools in unit testing by reducing testing time without sacrificing thoroughness. The well-known tools in everyday life are an editor, a compiler, an operating system, and a debugger. However, in some cases,

77 the real execution environment of a unit may not be available to a programmer

3.9 TOOLS FOR UNIT TESTING

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 array z is declared to have a range from z [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