Jody Hagins <jody-boost-011304@atdesk.com> writes:
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.
Easier than BOOST_ASSERT?
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.
That's all build system stuff and has nothing to do with the library. I do bjam test and get the same result.
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.
#include <boost/assert.hpp> int main() { ... BOOST_ASSERT( whatever ); ... BOOST_ASSERT( whatever ); }
For more complex tests, I use the unit test classes,
What classes, please?
but for almost everything else, the basic stuff is plenty.
I think that might be my point.
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.
Yes. What do you get from those macros that's very useful beyond what BOOST_ASSERT supplies? I really want to know. Some people I'll be consulting with next week want to know about testing procedures for C++, and if there's a reason to recommend Boost.Test, I'd like to do that.
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).
Proxy objects? Oh, I think someone described this to me: a proxy object is basically a stub that you use as a stand-in for the real thing? There was a guy I met at SD Boston who was all fired up with ideas for such a library -- I think he had written one. I encouraged him to post about it on the Boost list so the domain experts and people who really cared could respond, and he said he would, but... well, as in about 75% of such scenarios, he never did.
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.
I don't see why that was hard before Boost.Test. I have absolutely no problem writing new tests using BOOST_ASSERT. Having the Boost.Build primitives to specify tests is a big help, but as I've said, that's independent of any language-level testing facility.
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.
Blech. -- Dave Abrahams Boost Consulting www.boost-consulting.com