On Wed, 01 Feb 2006 09:34:14 -0500 David Abrahams <dave@boost-consulting.com> wrote:
It's all good and interesting but would you prefer minimal testing component? You stuck with a single BOOST_CHECK tool and couldn't figure out why particular assertion fails. You could use debugger but > using BOOST_CHEKK_EQUAL would give you much more change to figure it > you quicker without one.
Without a doubt, Boost.Test singlehandedly eliminated one of my biggest objections to test-first coding.
Which objection and how does Boost.Test eliminate it?
Early attempts were stopped because creating and running the tests were just too difficult and time consuming. Later attempts resulted in a mix of C/C++ with test scripts written in python, perl, ruby, etc. This was better, but there was still way too much going on, and it took a long time to use the system, write tests, run scripts, and such. The test framework was not clean and easy to use. I experienced a fair amount of effort in startup of using Boost.Test (about a week or so), but once I started using it and got a handle on the parts that seemed most use to me, it became very easy to write tests and integrate them into the build process. The framework allows for easy test-writing. I use the library, but part of my Boost install is to build all libs anyway, so it's not a big deal. I can run "make tests" at the top of my build tree, and it will build all the code, and run the tests. When I need more tests, I can simply create a new .cpp file with the basic few lines of template, and start inserting my tests. For more complex tests, I use the unit test classes, but for almost everything else, the basic stuff is plenty. Most of the TEST macros are very easy to use, though the documentation can be a bit confusing at times. I was quite surprised at the depth of this library after using it for a while. Thus, after integrating Boost.Test into my process, I find writing and maintaining good tests is not so difficult (I still have to write proxy objects for complex integration testing... someone needs to come up with a good solution for that). I really like the flexible error reporting. I do not set any environment variables in my shell. Instead, my makefiles handle all of that (by default, they do nothing, I think, which means the defaults are reasonable --- for me at least), and I can override it when I call make. When I am doing things the right way, I can quickly write up some tests, then develop until they all pass. Sometimes, as I write the implementation, I think of a strange scenario that I have to code around. When that happens I SHOULD go write the test. Before using Boost.Test I NEVER did that because it was too cumbersome, and often, the test needed to change as well causign more problems. The Boost.Test tools make writing them much simpler than my previous tools. I really don't have an excuse to do otherwise (at least for unit tests). I am still lacking good integration testing tools. Lots of my code is related to distributed systems, so I have to write lots of proxy objects. Blech.