1. You have a part you have to test, write a test program covering the *important* functionality. If your module contains a few objects with interfaces, write one test creating, modifying and destroying these objects as you see fit. Writing an interface is work, but it is also a set of strings that let you forget the puppet and yes, you will spend some time debugging errors *inside* the interfaced objects.
2. If your program does X and uses the above-mentioned interfaces, the mere fact that your program actually *does* X will be proof enough that - wait, no, sorry openssl, it was not. For debugging, you can write state and intermediate values to standard file descriptors or valgrind/ltrace up to some point, and your compiler may provide you with features that let you wrap function calls so that you can profile the program in other ways in which you see fit, which then still might not give you any more power as the mentioned tools. 3. If you insist in using a test framework, here, have [0]. The concept is a single line of preprocessing code you can extend to whatever you want to do with it. However let me explain for a minute why I think that mutest might not be such a good idea. Instead you should read the specification for the programming language [1] and any further tools and libraries you are using, because whatever interfaces from third-parties you're going to use are what will be making your life hell because you will at some point do something with these tools they might not yet have covered. cheers! mar77i [0] http://www.llucax.com.ar/proj/mutest/ [1] http://iso-9899.info/n1256.html
