Boost.Test tests require write access in current directory
In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy. I realize that Boost.Test may not want to depend on something like Boost.Filesystem, but it seems to me that any decent testing framework has to be able to get ahold of a temporary directory anyway, so maybe the ability to create files in /tmp or %TEMP% should be part of the library? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Fri Nov 30 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy.
Oh, and I realize this is going to be a problem as soon as my testing machines or processes are sharing a working copy, because they will collide when trying to write these files out. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams schrieb:
on Fri Nov 30 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy.
Oh, and I realize this is going to be a problem as soon as my testing machines or processes are sharing a working copy, because they will collide when trying to write these files out.
Boost.Filesystem and Boost.Serialization also create temporary files in the current working directory, IIRC. Markus
Markus Schöpflin wrote:
David Abrahams schrieb:
on Fri Nov 30 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy. Oh, and I realize this is going to be a problem as soon as my testing machines or processes are sharing a working copy, because they will
collide when trying to write these files out.
Boost.Filesystem and Boost.Serialization also create temporary files in the current working directory, IIRC.
Boost.Filesystem really should have facilities for creating temporary files and directories in places suitable for the particular system. Then Boost.Filesystem and other Boost libraries could use that mechanism for test files. I'm unlikely to get to this anytime soon. Providing such a facility in a system independent way is likely to be more complicated than it might appear on the surface, too. So if someone else wants to develop such a facility, I'd be very receptive. --Beman
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lk8fxeq1.fsf@grogan.peloton...
In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy.
I realize that Boost.Test may not want to depend on something like Boost.Filesystem, but it seems to me that any decent testing framework has to be able to get ahold of a temporary directory anyway, so maybe the ability to create files in /tmp or %TEMP% should be part of the library?
I am afraid you misunderstood the purpose of this file. This is not a temporary, but a very much permanent pattern file to match against. There are 2 mode of test execution. In regular (default) mode the test *reads* this file and matched tet output to it's content. User can request to save the pattern instead, in which case test does require write access to the location of the file, but it's the user who opt where to put it. Usually these files are stored somewhere around the test module itself. Gennadiy
participants (4)
-
Beman Dawes -
David Abrahams -
Gennadiy Rozental -
Markus Schöpflin