From: Mike Attili (yahoomail_at_[hidden])
Date: 2001-10-22 21:23:26
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> Subject: RE: [boost] unit test framework
> We really need to decide what dependencies we are willing to tolerate in
> the unit test library.
The unit test tools in CVS only make use of <cstdlib> and <config>.
Gennadiy's changes add <utility>, <smart_ptr>, and <progress>.
I've added <regex> locally and have thought about using <thread>, among
others. That's clearly not consistent with the needs of the Boost
Internal Regression Test Suite.
> If we want fuller functionality which comes at the cost of dependencies,
> that may well mean that test tools can't use unit test. Otherwise,
> dependency on regex would mean we can't test regex itself, and if regex
> fails for a platform, we can't test on that platform at all.
If I understand correctly, 'unit test tools' is intended to be a layer on
top of the 'test tools' and 'execution tools'. But, while trying to figure
out what the trade-off's are, I realized that I don't have a clear picture
of where the 'unit test tools' fit relative to the 'test tools'.
Specifically, if I'm writing tests for a new C++ library (Boost or
when should I restrict myself only to the facilities provided by 'test
versus those provided by 'unit test tools'?
My apologies if I've missed this in the docs.
I should say that my specific interest in the unit test framework is for
very short design-implement-test cycles (or what the 'agile' folks call test
first design). So, in addition to the requirements for regression testing,
I'm also interested in:
Making tests as simple to write as possible;
Getting very fast feedback
(thus <regex> to temporarily reduce the scope of testing);
Integrating tests into development tools;
Detecting resource leaks;
Maybe Boost isn't the right venue (since it's not exactly a library and I'd
be surprised if any test tools were considered for standardization) but with
such a great foundation I'd like to leverage as much as possible. And the
easier it is test, the better our end products.
Looking forward to helping any way that I can...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk