From: troy d. straszheim (troy_at_[hidden])
Date: 2005-09-18 14:58:05
I implemented some of that plan, to see how it would go. I tarred up
the test/ directory for you to peruse, it's at
I added a parameter to the jamfile, BOOST_SERIALIZATION_DATA_ROOT, which
gets set to BOOST_ROOT/libs/serialization/test/data by default. I
messed with test/test_tools.hpp and added a routine
test_serialization(), where the action is. It writes a type out to an
archive, reads it back in, and calls a template function check(), whose
default implementation is just
BOOST_CHECK(what_was_written_out == what_was_read_in);
I revamped test_vector.cpp, test_simple_class.cpp, test_set.cpp,
test_null_ptr.cpp, and test_variant.cpp. In the process I converted
these to use the cool autoregistering unit-tests. There are
corresponding tweaks in the jamfile.
test_serialization("name_of_test", object_to_test) will create tempfiles
in, as mentioned,
so this "name_of_test" has to be unique. My first implementation had it
calculating a name based on __FILE__ and an index, but this would cause
problems when you move test routines around.
test_vector.cpp and test_simple_class.cpp show how much bolierplate code
disappears with this scheme. test_variant.cpp and test_set.cpp show
writing a specialization of check() for the type being tested. In
test_null_ptr.cpp you have to write a wrapper class to ensure that the
two pointer types get written in the right order. This probably comes
up a lot, it makes me think that one would like to be able to serialize
boost::tuple (that one sounds interesting and tractable, I'll have a
look) so that you could just stack things up that way.
So I believe this clears the way for comparing different boost versions,
compilers and portable archives across platforms... test_serialization
just needs to scan some directories, deserialize from foreign archives,
and compare. I think that even if you don't do all that, the changes
are an improvement maintenance-wise. Whaddaya think?