How to write unit test and not get bored in development of FOSS project?

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:

1. You have exact specifications.
2. 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 unde开发者_如何转开发rstand 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.

I suggest to do no unit test at all. Work a bit on the project and see where it leads. If you cannot put enough motivation into doing the obviously right thing then work a bit on your problem do some refactoring, some bug fixing and multiple releases. If you then see what kinds of problems pop up think of TDD as one of the possible tools to solve them.

The problems can be

• low quality
• high bug fixing costs
• reluctance to refactor (i.e. fear to change existing code)
• suboptimal APIs (APIs are used to late to change)
• high testing costs (i.e. manuall testing)

There is a big difference between theoretically knowing that unit testing and test first are the right approaches and experiencing the pain and learning from that experience. Motivation will come with this experience.

TDD is not a panacea. It can be implemented in a horrible fashion. It should not become a check box in your project check list.

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.

write them jumping from unit tests to code to unit test to code... and so on.

Unit tests should follow all the best practices of production code, such as the DRY principle. If you get bored writing unit tests, you will also get bored writing production code.

Test-Driven Development (TDD) may help you, though, as you constantly switch back and forth between writing a unit test and then a bit of production code.

As others have told you: writing the tests first makes it fun. Your statements that it can't be done for a project that evolves need to be reconsidered. Actually the opposite is true. If you are going the agile route, you are highly discouraged to define everything up front. TDD fits in a paradigm that this is impossible and that change will happen. A book that makes this very clear, and gives examples of this is applying uml and patterns.

Try using TDD (Test Driven Development) - instead of writing your tests after the actual coding was done write them before and let them drive your design.

Due to the nature of the project a fair amount of automation is required - find a way to write the test once for one OS/compiler and then run it for all of the other options available.

Personally, I find writing code that I know works is quite exhilarating. But if you don't want to be bored writing unit tests then you'll need to cultivate a fascination for debugging.

To be serious, if you think that writing unit tests is boring and slow, you really need to re-address how you write them. I suggest you investigate using Test Driven Development. Write the tests in the programming language and run them automatically. Use the feedback from the tests to shape your code.

There are Test First frameworks for pretty much any language you care to mention, inspired by Kent Beck and Erich Gamma's work with JUnit. The Wikipedia article on TDD has more info, including a helpful link to a list of frameworks organized by language. Find out more.