-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Reid Sent: May-21-12 4:48 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] First attempt at using Boost::Test is a flop:

the

program ends with an exception related to std::string but I don't use any

On 21/05/12 04:50, Ted Byers wrote:

...

Here is the full output from my program:

$ ./decision.test.suite

terminate called after throwing an instance of 'std::logic_error'

what(): basic_string::_S_construct NULL not valid

Aborted (core dumped)

Now, all the code in this program is focussed on number crunching, so none of it involves strings. I am guessing that I missed something in setting up a test suite.

Just a guess but might it be trying to stream one of your objects to a std::ostream? Do your classes support this behaviour? I think the library offers different macros, some of which will print values when the test fails, others don't. Perhaps you can try those.

No, none support IO. But then, none have data to write out. They're function objects, derived from one or the other of the function objects defined in STL. Actually, I found the culprit. I had assumed initially that all I'd needed was defined in a single header: #include But, I continued investigating after I posted here, and observed that in the framework example it also had: #include I added that to my file, and it still compiled, but what a difference at run time. The program now runs to completion without an exception. What I don't have in an explanation, or why I haven't found, yet, documentation that says what headers are needed in what test scenarios. I have learned, however, some of the limitations of the algorithms I use to compute the moments of a distribution. There is a rather poor, but commonly recommended algorithm that works only when the mean and standard deviation are roughly the same order of magnitude. It fails miserably when the mean is orders of magnitude greater (in absolute value than the standard deviation. The usual two pass algorithm and the best single pass algorithm also work well when the mean is many orders of magnitude greater than the standard deviation; although, surprisingly the single pass algorithm is more accurate than the two pass algorithm in this edge case. But none that I have tried so far works when the standard deviation is orders of magnitude greater than the mean. But perhaps in this edge case, it may be statistically impossible to get an accurate estimate of the mean. I also hit a limitation of BOOST_CHECK_CLOSE. In testing my code to check the accuracy of the algorithm for the standard normalized normal distribution, of zero mean and unit variance, it always failed, giving an infinite percent accuracy. Changing the distribution to mean of one and variance of one resulted in the test passing. Clearly the incorrect result of a failed test was due to a division by zero, and thus BOOST_CHECK_CLOSE clearly can not compare a double with 0.0, and that strikes me as a significant limitation. It is true that for my purposes, simply shifting the distribution to the right by one meets my needs, I can imagine cases in which that is not viable. Is there another macro that is specialized for the case when the expected outcome, for a double, of a given calculation is zero? Thanks again. Cheers Ted

"Ted Byers" writes:

...

On 21/05/12 04:50, Ted Byers wrote:

...

Here is the full output from my program:

$ ./decision.test.suite

terminate called after throwing an instance of 'std::logic_error'

what(): basic_string::_S_construct NULL not valid

Aborted (core dumped)

Now, all the code in this program is focussed on number crunching, so none of it involves strings. I am guessing that I missed something in setting up a test suite.

Actually, I found the culprit. I had assumed initially that all I'd needed was defined in a single header:

#include

But, I continued investigating after I posted here, and observed that in the framework example it also had:

#include

I added that to my file, and it still compiled, but what a difference at run time. The program now runs to completion without an exception. What I don't have in an explanation, or why I haven't found, yet, documentation that says what headers are needed in what test scenarios.

If memory serves me right, #include pulls in the full code of the library. If you only #include you need to link against the precompiled Boost.Test library. See http://www.boost.org/doc/libs/1_49_0/libs/test/doc/html/utf/user-guide/usage... for details. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962

AMDG On 05/21/2012 04:48 PM, Ted Byers wrote:

Thank you one and all who replied. Your replies were quite helpful.

I have a couple final questions.

1) What does such a test program return to whatever invoked it. But that I mean, can I build the testsuite using make, have make execute the testsuite program, and fail with an error if one of the tests fail? If so, I can create another target in my makefiles that do just that, and still another one that checks code into an SVN repository after doing an update against the repository and rebuilding everything, and verifying the testsuite builds and runs successfully (and bales before the check-in if one of the tests fails).

If any test fails or crashes, the test program returns non-zero. What you want sounds like exactly what we do in our own regression tests.

2) Is there a tool included in Boost::Test that provides support for code coverage, that can be used to check to verify that all the code in the source code is tested by one or more test cases in the test suite? I have found several open source tools (gcov, trucov, and covtool), but have not yet had a chance to investigate them. Again, I want an automated way to ensure that all code in my project is subjected to one, or, preferably more, tests.

This isn't really something that can be handled from within C++. You need an external tool, or compiler support. In Christ, Steven Watanabe