Effective use of CppUnit with an application
Brought to you by:
blep
Menu
▾
▴
I asked this in the extreme programming list a few days ago, but I only got a couple (opposing) answers, so I'm not much better off than I was before. Maybe someone here will be able to give me some better advice.
I have used CppUnit for the last year and a half for testing static libraries, and everything works like a charm. I create a new executable and link it with the library I'm testing. Everything is fine.
Now I want to use CppUnit to test not just a static library, but the classes in a Win32 application itself.
I think my options are:
1) Create a new project for all the tests that also includes all the classes and header files that I want to test, and compile and link with it. The main problem with this approach is that I need to maintain two parallel projects, which is usually a sign of something now being done correctly.
2) Add the CppUnit tests to the application itself. Maybe run them automatically in debug mode or based on a command-line switch. No need for a separate project, but it adds more "stuff" to the main project. It also will force me to use RTTI (at least in debug mode, and I won't be able to test it in release).
3) Take all my classes, throw them in a static library, and make so my application code is just one main file instantiating the correct classes. Then I can test it like any other static library. It seems that it's adding some complexity that shouldn't be there.
Any recommendations? I'm torn between 1 and 2, but I'm open to any suggestions. What has worked well for you in the past?
In case you're curious, I'm using this for my project The Bidding Imp (http://biddingimp.convexhull.com), an automatic Ebay bidding program. It's open source and I've been trying to develop it in the extreme programming style. Now I want to refactor it to allow for test-first development with CppUnit.
Thanks.
--Noel
Hey there Noel- I woulda thought you were up on this stuff already. :)
Ok- I'm a hack and I believe in the simplest thing that could possibly work. I don't mind the overhead of RTTI because I believe it to be small for most apps. So, what that allows me to do is...
I have a Test() routine that gets called "right away" and it returns a boolean indicating that the tests passed or not. If the tests fail, the app doesn't run. This forces me to fix everything before I get to fool around with the app.
I've thought that even slicker down the road would be to put the testing harnesses in a DLL that gets loaded (or not) based on #ifdef TEST or something. I definitely like running the test code on release code (found inconsistencies just yesterday in fact in the MSVC compiler).
Basically I have Debug and Release build targets and then put together a Release (NO_TEST) target as well that excludes the tests.
I'm using this stuff in some fashion at work, but the main app that we're developing is not test-friendly and the other developers are hostile to the idea that they might make a change and cause someone else's code to break being shown to them with testing and stopping the app... Ahh well, what can you do?
Good luck.
-tom!