[C++-sig] Outstanding Jobs for v2 release

[David Abrahams]

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Saturday, July 13, 2002 2:47 PM
Subject: RE: [C++-sig] Outstanding Jobs for v2 release


> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > The way you've currently written the tests, there's a lot of printing
to
> > std::cout
> > and via Python print statements without any result checking. If there's
a
> > problem with the result, I'll never know it. That's a good reason to
use
> > doctest instead.
>
> Could you have a look at the attached unittest example for dict? If it's
ok
> for you,

I can't really tell. It doesn't seem to test very much, but I could be
wrong -- as I said I'm not familiar with unittest. It certainly seems to
come with a lot more syntactic baggage than doctests do, which makes it
harder to see what the test is doing.

BTW, the point of the exercise() function in the list test is mostly to
check that the templated list member functions interact properly with types
other than python::object.

> I would do the same for str. I'm not used to use python in
> interactive mode and you have to set pathes or move files around to get
the
> test running. So doctest feels not very comfortable to me - but I might
be
> missing something.

No, all you have to do is plug it into the libs/python/test/Jamfile in the
same way as the other tests. "bjam test" runs all tests and "bjam
<test-name>.run" runs your specific test.

> BTW: It seems that the python test scripts are executed twice. Why? Has
it
> something to do with doctest?

No, just that the Jam testing rules for Python are a little unsophisticated
and it hasn't been worth my time to fix them. It's actually building the
".run" and ".test" targets. The ".test" target is supposed to build only
when out-of-date, but the ".run" target builds (i.e. runs the test)
whenever you request it.

> > [I told you writing good tests would be the hard part -- except for
> > documentation, of course, which is the really hard part ;-)]
>
> Yes, but I'm here to learn. I know that writing tests is not easy, but
I'm
> just experiencing how long it could take. ;-)

Please try doctests; it's really quite easy if you use the build system.