I also like the "if you haven't got the time to do it right, where are you going to find the time to do it over?" philosophy. For my draughts program, I have automated unittesting (using Boost.Test, and previously GoogleTest) in place.Sven Schüle wrote: From my experience it is simply the wrong view to say that "fixing some error checking is a waste of time". It is always cheaper to include error checking immediately when designing the algorithm. If you add it later then you add much more testing effort, and there is a high risk that you introduce new errors by changing the algorithm (or its implementation) to include error checking. Better include it right from the beginning.
Part of that "error checking" topic can also be to include ASSERT's, which can sometimes help to reduce the amount of error checking code of the release version drastically. (But ASSERT's are not always the right solution, e.g. not always applicable for external input.)
To a certain degree this does also apply to chess programs, where an FEN parser is only one (perhaps less important) example.
Underestimating the need for error checking and/or ASSERT's is one of the best ways to unreliable code.
Sven
All the low-level routines (bit-twiddling, move generation, hash lookup/storage) are automatically checked exhaustively (at least the corner cases) on *each* compile. It's simply a post-build event in Visual Studio, so you cannot ever break code without noticing immediately. The code simply fails to build successfully if any unittest fails! It only takes a few seconds (on a compile time of a minute) to run this. The more time consuming tests (search, perft) are not done on every build, but are automatically scheduled for an overnight build (they tend to take between 2 and 6 hours).
Surprisingly, I never read about anyone at this forum doing unittesting. Is that because people consider this a hobby and don't like the effort, or is it because of lack of familiarity with the concept?