I'm considering migrating my unit tests to boost.test, however there is a feature I need which I can't find in boost.test. Please correct me if I'm wrong. 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. 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. 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? Thanks, Emil Dotchevski
On 3/9/07, Emil Dotchevski <emildotchevski@hotmail.com> wrote:
I'm considering migrating my unit tests to boost.test, however there is a feature I need which I can't find in boost.test. Please correct me if I'm wrong.
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. 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.
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?
Well, it looks as it would be better to split the functionality into three parts: 1. Qualification of file name without path. I do not know if such a utility is already in one of Boost libraries. If not, it would be nice to have one, and not only for tests. In my experience, I qualified filenames many times in different programs that change current directories. Some OS do not have directory trees, but I did it under MS Windows, Linux, VMS, DOS, and old Mac OS (9 and earlier). So, such utility belongs not to Test, but to some more generic library. 2. Testing if expected files were created. 3. Testing that the created file contains right data. It can be done by comparing them to model files, like you do, or in other ways. ---- Critique: - A bit unusual is that you put files without names in the same directory as the executable program. Typically, they are in the current directory. - Extension "svd" is hard-coded; why? - The naming system is unusual and, I would say, unintuitive. I would either add the extra extensions at the end: frame1.tga.svd frame2.tga.svd or even better would assign the model files the same names, but put them in a separate directory: model_dir/frame1.tga model_dir/frame2.tga Actually, it is what I usually do. Very convenient when comparing with previous versions that works: just move all files to the "model" directory before running the test. I used external utilities for comparison, fc [/b] in Windows (and DOS) and diff or cmp under Linux, but, of course, it can be done by C++ codes.
"Emil Dotchevski" <emildotchevski@hotmail.com> wrote in message news:BAY110-DAV119EE6BBAB2DA1F07B4FEFD4780@phx.gbl...
I'm considering migrating my unit tests to boost.test, however there is a feature I need which I can't find in boost.test. Please correct me if I'm wrong.
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.
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.
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? Gennadiy
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
"Emil Dotchevski" <emildotchevski@hotmail.com> wrote in message news:BAY110-DAV114E376C7E9857A737E911D47C0@phx.gbl...
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.
Umm. Indeed output_test_stream woudln't help you her.
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.
I still do not see what exactly do you want from UTF. Do you want me to compare binary files or register which files to compare somewhere? Gennadiy
participants (3)
-
Emil Dotchevski -
Gennadiy Rozental -
Yuriy Koblents-Mishke