[boost] [test]Re: [serialization] portable_binary_archive

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
> is
> 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
> the
> 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 
occasionally.

    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 
frequently.

e) That the tests move to the boost unit test library rather than the test 
exec library.
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.

Robert Ramey