I’m developing cross-platform project that would support :
- Four C++ compilers – GCC, MSVC, SunStudio, Intel,
- Five Operating Systems: Linux, OpenSolaris, FreeBSD, Windows, Mac OS X.
I totally understand that without proper unit testing there is no chance to perform proper QA on all these platforms.
However, as you all know writing unit tests is extremely boring and slow down development process (because it is boring and development of FOSS software shouldn’t be such)
How do you manage to write good unit-testing code and not stop writing code.
If you at least get salary for this, you can say – at least I get something for this, but if you don’t, this is much harder!
Clarification:
I understand that TDD should be the key, but TDD has following very strict restrictions:
- You have exact specifications.
- You have fully defined API.
This is true for project that is developed in customer-provider style, but it can’t be done for project that evolves.
Sometimes to decide what feature do I need, I have to create something and understand if it works well, if API is suitable and helps me or it is ugly and does not satisfy me.
I see the development process more like evolution, less development according to specifications. Because when I begin implementing some feature, sometimes I do not know if
it would work well and what model would it use.
This is quite different style of development that contradicts TDD.
On the other hand, support of wide range of systems requires unit tests to make sure that
existing code works on various platform and if I want to support new one I only need to
compile the code and run tests.
Personally, I don’t find testing boring. It’s the first time I get to see my code actually run and find out whether it works or not!
Without some form of test program to run the new code directly, I wouldn’t get to see it run until after I’ve built a user interface and wired it all together to make the new bits available through the UI and then, when it doesn’t work the first time, I have to try to debug the new code, plus the UI, plus the glue that holds them together and dear god, I don’t even know what layer the bug is in, never mind trying to identify the actual offending code. And even that much is assuming I still remember what I was working on before I went off on an excursion into UI-land.
A proper test harness bypasses all that and lets me just call the new code, localize any bugs to the tested section of code so they can be found quickly and fixed easily, see that it produces the right results, get my “it works!” rush, and move on to the next bit of code and my next rush of reward as quickly as possible.