From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-17 10:53:16
troy d. straszheim wrote:
> Robert Ramey wrote:
>> There might be people interested. You might upload it to the vault.
>> You don't have to write a test program. You can use all the boost
>> archive test programs with your own archives by following the
>> instructions in the documentation Reference/Archve Class Reference/
>> Testing. The batch file run_archive_test.bat will run all the tests
>> with your archive.
> Right. This testing architecture I've used; the
> portable_binary_(i|o)archive and the polymorphic version pass all the
> existing serialization tests, alongside the regular binary, text, and
> xml archives (I just got all that done, it's sitting here on disk.)
> So that much is good. But of course the real test of such an archive
> to verify that you can correctly read on platform A what was written
> on platform B, and vice-versa. I've done this testing (probably to
> point of overkill), but again with a different testing scheme. One
> thing inherent to the problem is that you are required to have
> portable binary archives checked in to source control.
This is something that my test suite should test but doesn't. Regardless of
what happens with your portable_binary archive, It would be very helpful to
have the test suite enhanced to explicitly test archive portability.
Since we're just talking, So I would like to see the following changes in
the test suite:
a) That output of the tests go to a particular directory. There would be a
directory for each column in the test matrix.
b) There would be a set of directories for each boost release 1.32, 1.33,
c) Tests would be run on the four combinations which result from:
i) set of archives created by the previous version
ii) set of archives created by other compilers (portable archives only)
This would result in a HUGE number of tests so it couldn't be run any
more than on an occasional basis. But it would be helpful to run very
This would require more investigation into boost test in order to find
out what facilities are already there for helping out with ths.
d) An alternative to the above might be just to make some specific tests
for backward compatibility and for cross compiler compatibility. This is
probably a better idea as it would result in tests that could be run more
e) That the tests move to the boost unit test library rather than the test
e) A number of tests leave memory leaks. I would prefer to fix these if it
were possible to do so without making the tests so complex that they are no
longer serve as convincing tests.
Just food for thought.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk