Boost Testing :
From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-09-08 17:25:59
Robert Ramey wrote:
> a) I want to test my changes in process_jam_log so that
> I can be sure that they don't break boost testing. Locally
> I can test that the support library_status and compiler_status.
> b) check in these changes knowing that they won't break
> testing. Note that since the output of process_jam_log
> isn't specified anywhere - there is no way I can really
> check that its correct other than by running the programs
> which use that output. - that is regression.py - and
> that one fails silently if the input isn't correct.
> c) then my library_status will work and I can
> ask users who have problems with the serialization
> library to run the tests on it. [...]
> Soooooo - THAT is what I'm looking for. Am I being
I'd like to point out one important thing -- nothing in
the above list appears to be related to Boost.Build,
therefore it probably should not be discussed on Boost.Build list,
but on the boost-testing list, where I cross-post this email,
and where all follow-up should be directed.
As far as testing process_jam_logs goes -- would you mind telling
what's missing in the current output? Basically, an easy way
to test your changes is to run old process_jam_logs, run new process_jam_logs,
and make sure that the produced xml files are identical.
As far as library_status.cpp goes, I've just looked at SVN at it
appears that file has large blocks of code common to compiler_status.cpp.
Except that it was reformatted to use different indentation, which makes
it impossible to understand the real differences. I don't think this
code duplication is OK.
Speaking about compiler_status.cpp, what you say is false. Here's what I've
bjam --dump-tests -d+2 > log 2>&1
cat log | process_jam_log --v2
compiler_status --v2 /home/ghost/Work/Boost/boost-svn status.html status-links.html
Everything is from SVN HEAD. I have got the attached two files, and they
make sense to me. The only problem with those files is that all
tests are marked as having warnings; this is most
likely a result of:
1. Somebody changing process_jam_logs, and
2. Not reporting of warnings by the current web pages,
so the bogus warning remained unnoticed.
We can probably fix that, but I surely don't think that copy-pasting
compiler_status.cpp is the first approach to the fix.