Dr. Dobb's Journal - February 2008 - (Page 66)

d02mila_p5ma 12/12/07 12:37 PM Page 66 State of the Art by Carlo Milanesi Statically Testing C++ Code A utility to check library usability Assume you have just written a beautiful function library. You could have used any programming Carlo is a CAD/CAM software developer in Bergamo, Italy. You can contact him at carlo.milanesi@libero.it. language, but the library appears to other programmers as a sequence of functions callable by a program written in C (or in languages that conform to C-like function calling conventions). But before delivering it to users (who are application programmers themselves), you want to be confident about the library’s correctness. Consequently, you write a program that uses the library. However, that program presumably won’t invoke every function in every possible way. So to guarantee reasonable quality, you need to write a testing program that invokes the library functions, passing a variety of possible parameter values and checks if the outcome matches expected results. The testing program can be written in a different programming language, provided it interfaces with the library’s functions. Because a buggy function could crash a program, you could divide the testing program into several small programs and launch them sequentially from a script. If a program then crashes, the script can proceed to the next program. } try { process_file("readable_file"); } catch ( ) { failure("unexpected exception"); } Exception-Raising Libraries Now assume that your library isn’t a simple C function library, but rather a library that exports functions or classes usable only by C++ code. In addition, exception-handling issues must be considered. Actually, the C++ functions to test could raise exceptions, both expected and unexpected. The specification of every function can (and should) declare which exceptions may be raised while executing such functions. For example, if I call a function passing as a parameter the name of a nonexistent file, I could expect that an exception of a specific type is raised by that function. And if I pass the name of an existing but unreadable file, an exception of another type is expected. Finally, if passing the name of a readable file, no exception is expected. Here is the code: try { process_file("inexistent_file"); } catch (file_not_found_exception &e) { success(); } catch ( ) { failure("unexpected exception"); } try { process_file("read_protected_file"); } catch (file_unreadable_exception &e) { success(); } catch ( ) { failure("unexpected exception"); To properly test the library’s exception-raising feature, every function call in the testing program must be put in a try block. After the calls for which a specific exception is expected (file_not_found_exception or file_unreadable_exception), a catch block for the expected exception type must be put. And for every call, a catch-all block must be put after the possible specific catch block to ensure that every unexpected exception is handled. There are several open-source frameworks— Boost.Test, CppUnit, CppUnitLite, NanoCppUnit, Unit++, and CxxTest, among others—that facilitate the development of automatic testing programs of C++ modules. Libraries That Can’t Be Compiled A testing issue rarely considered by textbooks and testing frameworks is this: “Are you sure that in using your library, the application program will be correctly compiled and linked when it should?” When you use libraries written in C, this isn’t a big issue—library header files clearly define which functions are exported by the library, and it is always clear which function is called by a statement of the testing program. Therefore, in the testing program every library function is called at least once. If you can smoothly compile and link the testing program, then you can be 66 Dr. Dobb’s Journal l www.ddj.com l February 2008 http://www.ddj.com

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

Dr. Dobb's Journal - February 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook South American Software Development Conversations Inside Visual Studio 2008 BibPort: Creating Bibliographic References Continuous LINQ The ZK Framework Static Testing C++ Code The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - February 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.