Re: ANN: new release of FRUCTOSE C++ unit test framework - c++

In article <1179936029.107038.232600@p77g2000hsh.googlegroups.com>,
apm35@student.open.ac.uk wrote:

> On 23 May, 15:33, Roy Smith <r...@panix.com> wrote:
> > I also wonder why you implemented the assertions as macros instead of
> > functions.
>
> For the same reason that the C-style assert macro is a macro; in order
> to be able to print the expression passed. A function would be forced
> to accept the assertion expression as a boolean which would just print
> as true or false. The preprocessor is enable to treat the expression
> as text which can be passed to printf (in the case of C) or stdout/
> stderr (in the case of C++). If there is someway to do this in C++
> using functions instead of the preprocessor I would welcome this and
> would convert fructose assertions to use functions. What mechanism did
> you have in mind?
>
> -Andrew Marlow

I guess I was thinking that just printing the name of the test case would
be good enough, because then you would just go look at the source code of
the test to find out what had failed. This works if you can strictly stick
to the ideal of "one assertion per test case", but I guess that's often an
ideal which is difficult or impractical to achieve.

My next thought was that even if you had multiple assertions per test case,
you could just print out the line number of the failing assertion, but to
do that you need __LINE__, and __FILE__, so I guess you're right back to
having to use macros.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Roy Smith wrote:
> I guess I was thinking that just printing the name of the test case would
> be good enough, because then you would just go look at the source code of
> the test to find out what had failed. This works if you can strictly stick
> to the ideal of "one assertion per test case", but I guess that's often an
> ideal which is difficult or impractical to achieve.

I would agree with that statement. Often, the way I code unit tests is
to just assert a simple one-time use of a function, which usually only
involves one assert; just as often, however, I want to test a use that
involves a few or several calls working in concert. Usually I'm
asserting postconditions between these calls.

Additionally, sometimes functions have several postconditions, and even
using one function, I want to assert each postcondition separately, so
that I may determine easily which was violated. To get this
information, it helps to have the file and line.

--

John Moeller
fishcorn

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 27 May, 18:29, Roy Smith <r...@panix.com> wrote:
> In article <1179936029.107038.232...@p77g2000hsh.googlegroups.com>,
>
>
>
> a...@student.open.ac.uk wrote:
> > On 23 May, 15:33, Roy Smith <r...@panix.com> wrote:
> > > I also wonder why you implemented the assertions as macros instead of
> > > functions.
>
> > For the same reason that the C-style assert macro is a macro; in order
> > to be able to print the expression passed. A function would be forced
> > to accept the assertion expression as a boolean which would just print
> > as true or false. The preprocessor is enable to treat the expression
> > as text which can be passed to printf (in the case of C) or stdout/
> > stderr (in the case of C++). If there is someway to do this in C++
> > using functions instead of the preprocessor I would welcome this and
> > would convert fructose assertions to use functions. What mechanism did
> > you have in mind?
>
> > -Andrew Marlow
>
> I guess I was thinking that just printing the name of the test case would
> be good enough, because then you would just go look at the source code of
> the test to find out what had failed. This works if you can strictly stick
> to the ideal of "one assertion per test case", but I guess that's often an
> ideal which is difficult or impractical to achieve.

FRUCTOSE provides mechanisms to assert in the case where the tests are
driven by a table of test data. Not only is __FILE__ and __LINE__
needed here but also the line in the test data table. This is another
case for using a macro. I intend to add more macros to extend the
assertions that can be done for floating point comparisons so that
these can be done inside test data loops. This will be done in a
future release, so I have more macros on the way!

>
> My next thought was that even if you had multiple assertions per test case,
> you could just print out the line number of the failing assertion, but to
> do that you need __LINE__, and __FILE__, so I guess you're right back to
> having to use macros.

Yes, I think so. I do welcome suggestions as to how it might be done
without them but I would be very suprised if it could be done without
them.

-Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]