Dr. Dobb's Journal - March 2008 - (Page 23)

with most build systems, report their results in a reasonable time, create easy-to-understand reports, and have a manageable falsepositive rate. There is no substitute for rigorous unit, regression, and integration testing. Ideally, your tests would feed in as many combinations of inputs and conditions as possible such that all parts of the code are exercised thoroughly. Statement coverage tools can help you develop a test suite that makes sure that every line of code is executed at least once. But as all programmers know, just because a statement executes correctly once doesn’t mean it will always do so—it may trigger an error only under a very unusual set of circumstances. There are tools that will measure condition coverage and even path coverage. These are all helpful for exercising these corner cases, but achieving full coverage for nontrivial programs is extraordinarily time consuming and expensive. This is where static analysis shines. Static analysis examines paths and considers conditions and program states in the abstract. By doing so, it can achieve much higher coverage of your code than is usually feasible with testing. Best of all, it does all this without requiring you to write any test cases. This is the first major way in which static analysis reduces the cost of testing. The cheapest bug is the one you find earliest. Because static analysis is a compile-time process, it can find bugs before you even finish writing the program. This is usually less expensive than if you have to find them by writing a test case or debugging a crash. leading to a statement, the analysis may determine that if variable x is greater than 10, then pointer p may be NULL. As this execution proceeds, the analysis looks for anomalies. For example, if p is dereferenced at that statement, then the analysis issues a report that a null pointer dereference may occur. A good tool explains the reasoning the tool used to arrive at that conclusion, which is essential to help you determine whether the report is a true or false positive. This is the essential difference between testing and static analysis: Testing uses real inputs and concrete values, whereas static analysis uses symbolic inputs and abstract values. The appeal of the latter is that because each abstract value represents a wide range of possible concrete values, static analysis can take into account many possible program states simultaneously, and so achieve much greater coverage than testing. Static analysis finds places where violations of the fundamental rules of the language or libraries might lead to errors. The The cheapest bug is the one you find earliest How Tools Perform Analysis You can think of an advanced static-analysis tool as doing a “pretend” or abstract execution of your program. Instead of variables containing actual concrete values, they contain abstract values. Values that are inputs are given symbolic names, too. The analysis then pretends to execute the program using these symbols by following paths through the code. As this execution proceeds, the analysis may learn facts about the variables and how they relate to each other. For example, because of the conditions on the path March 2008 l www.ddj.com l Dr. Dobb’s Journal 23 http://www.scitools.com http://www.scitools.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.