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
Received on Wed Feb 25 2015 - 21:38:19 CET