I was looking at the Boost web page describing the Boost test policies, at http://www.boost.org/development/test.html. I was not sure what I needed to use to design tests for possible Boost software. I noticed that it was not required to use Boost Test in order to do so, but that there was an "Optional (but highly recommended)" section for using Boost Test. But neither of the links there are valid any longer, and while Boost Test still has a Unit Test Framework I did not find any Test Tools section for simple test programs, although perhaps the execution monitors or minimal test in Boost Test was originally meant. Anyway the page needs to be updated in regard to Boost Test links. I also found the lightweigt_test.hpp in Boost detail, so I was wondering whether or not that is now considered a viable enough choice for designing Boost component's tests.
AMDG Edward Diener wrote:
I was looking at the Boost web page describing the Boost test policies, at http://www.boost.org/development/test.html. I was not sure what I needed to use to design tests for possible Boost software. I noticed that it was not required to use Boost Test in order to do so, but that there was an "Optional (but highly recommended)" section for using Boost Test.
But neither of the links there are valid any longer,
I fixed the links.
and while Boost Test still has a Unit Test Framework I did not find any Test Tools section for simple test programs, although perhaps the execution monitors or minimal test in Boost Test was originally meant. Anyway the page needs to be updated in regard to Boost Test links.
I also found the lightweigt_test.hpp in Boost detail, so I was wondering whether or not that is now considered a viable enough choice for designing Boost component's tests.
In Christ, Steven Watanabe
On Tue, Aug 24, 2010 at 7:47 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
I also found the lightweigt_test.hpp in Boost detail, so I was wondering whether or not that is now considered a viable enough choice for designing Boost component's tests.
It always has been. While Boost.Test has some cool features, they don't seem to markedly improve the quality of testing in a library that uses Boost.Test, which mostly depends on the skill of the test designer. Also, if you use lightweight_test.hpp you are liable to continue to get useful test results even if Boost.Test should be broken ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 25/08/10 06:29, Dave Abrahams wrote:
It always has been. While Boost.Test has some cool features, they don't seem to markedly improve the quality of testing in a library that uses Boost.Test, which mostly depends on the skill of the test designer. Also, if you use lightweight_test.hpp you are liable to continue to get useful test results even if Boost.Test should be broken ;-)
Note that lightweight_test is also useful to run Boost liek UT on embedded platform where Boost.Test may not be abel to be compiled.
Dave Abrahams wrote:
On Tue, Aug 24, 2010 at 7:47 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
I also found the lightweigt_test.hpp in Boost detail, so I was wondering whether or not that is now considered a viable enough choice for designing Boost component's tests.
It always has been. While Boost.Test has some cool features, they don't seem to markedly improve the quality of testing in a library that uses Boost.Test, which mostly depends on the skill of the test designer. Also, if you use lightweight_test.hpp you are liable to continue to get useful test results even if Boost.Test should be broken ;-)
Actually this can be a big problem. I was having trouble testing on my own machine and in the trunk because boost.test was being worked on while I was using it. So I moved to lightweight test so that I would be dealing with only one thing at a time. Now, I run all my local tests against the release branch of all the libraries not my own. So this would not be a problem for me to move back (except the work of actually moving back). Of course the trunk tests still test all the library changes "all at once" so the problem can still occur. But I don't check into the trunk until I've tested here so it's not such a big deal anymore. Robert Ramey
Robert Ramey <ramey <at> rrsd.com> writes:
Actually this can be a big problem. I was having trouble testing on my own machine and in the trunk because boost.test was being worked on while I was using it. So I moved to lightweight test so that I would be dealing with only one thing at a time.
I do not believe this is *big* problem. Boost.Test is rather stable in a last couple years. You should be very unlucky to intersect with my update phase.
Now, I run all my local tests against the release branch of all the libraries not my own.
This is a good practice in any case and avoids any possibility of issues like above. Gennadiy
participants (6)
-
Dave Abrahams -
Edward Diener -
Gennadiy Rozental -
joel falcou -
Robert Ramey -
Steven Watanabe