|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-13 14:02:10
> Hmm. Looks like you are mixing a looot of staff into single bowl.
>
>> Essentially what I need is a system which, given a file name without
>> path,
>> returns a fully qualified file name that places the file in the same
>> directory where the executable is, and also remembers the file name in an
>> internal file name list.
>
> Looks like something what boost::filesystem should allow you to do.
Indeed my current implementation uses boost::filesystem. The part of this
functionality that is in the testing domain is keeping track of which files
have been created by the test, so that they can be compared against their
svd versions.
>>When a unit test finishes, the system goes through
>> all files requested by the unit test. For each file, it compares it to a
>> file with the same name but .svd extension. If a matching .svd file does
>> not
>> exist, or if it differs, the system fails the unit test, specifying the
>> name
>> of the mismatched file.
>
> How do you plan t compare them? using diff? Than it somewhere in
> Boost.Build domain.
I should have mentioned that what I need is a binary diff, but a better
implementation would allow the user to supply the diff function.
I agree that all of this could be implemented in Boost.Build. The idea would
be to monitor the files created by the executable, and compare them to their
known "good" versions. The tricky part is how do you know which of the
created files should be compared. Note that in my current system, a test can
create all kinds of files through the standard libs interface or even
boost::filesystem, but the system only compares the files whose names have
been obtained through the interface I described in my original post.
>> For example, if I request two file names:
>>
>> frame1.tga
>> frame2.tga
>>
>> the system would be comparing them to
>>
>> frame1.svd.tga
>> frame2.svd.tga
>>
>> and if it finds any differences, or if the .svd files don't exist, will
>> fail
>> the test.
>>
>> Does this sound as a reasonable functionality to add to boost.test?
>
> I believe Boost.Test already have something similar or even better in some
> regards. Did you take a look on output_test_stream component?
I do not see how output_test_stream can help.
Emil Dotchevski
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk