On 13.11.2017 15:52, Peter Dimov via Boost wrote:

Stefan Seefeld wrote:

...

Hi there,

I'm trying to write a test that needs to access a data file. As I'm surely not the first wanting to use external data in my tests, I wonder whether there are established "best practices" or idioms when using Boost.Build and Boost.Test.

Use the "input files" parameter of the run rule.

run my_test.cpp : : my_datafile.txt ;

This will pass my_datafile.txt (with the correct path) to your test executable in argv[1].

But using boost::test I don't have direct access to argv, or do I ? I don't get to write my own main() function...

I just fixed the date_time tests in this manner:

https://github.com/boostorg/date_time/commit/2434bc8f4d7e5d921eeccd4b138174e...

Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

If it doesn't already, boost test main ought to save argc and argc for access by tests. On Nov 13, 2017 13:07, "Peter Dimov via Boost" <boost@lists.boost.org> wrote:

Stefan Seefeld wrote:

...

...

Use the "input files" parameter of the run rule.

run my_test.cpp : : my_datafile.txt ;

This will pass my_datafile.txt (with the correct path) to your test > executable in argv[1].

But using boost::test I don't have direct access to argv, or do I ? I don't get to write my own main() function...

I don't quite understand Boost.Test so I'm not sure which is the idiomatic way to both use automatic registration for convenience and still be able to access argv[1], but it ought to be possible somehow. :-)

http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boos t_test/tests_organization/test_suite.html http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boos t_test/tests_organization/test_suite/master_test_suite.html

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

Thanks everyone for the replies. What I ended up doing (for now) is simply computing the (absolute) path to the test source file, using fs::path here = fs::absolute(fs::path(__FILE__)).parent_path(); and compute the data path from that. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

AMDG On 11/13/2017 01:54 PM, Robert Ramey via Boost wrote:

<snip> Hmm - I do this in serialization library. My believe is that the tests are run while the current directory is set to the test directory.

Boost.Build never changes the current directory. If you run the tests from the test directory, then this will work. If you run them from somewhere else (say $BOOST_ROOT/status), then it won't.

So if you put a copy of your external data as file in your test directory, you should be able to just open it without including any prefix.

In Christ, Steven Watanabe

Le 13.11.17 à 22:17, Stefan Seefeld via Boost a écrit :

On 13.11.2017 16:06, Steven Watanabe via Boost wrote:

...

AMDG

...

<snip> Hmm - I do this in serialization library. My believe is that the tests are run while the current directory is set to the test directory. Boost.Build never changes the current directory. If you run the tests from the test directory, then

On 11/13/2017 01:54 PM, Robert Ramey via Boost wrote: this will work. If you run them from somewhere else (say $BOOST_ROOT/status), then it won't.

Ah, but the cwd surely differs depending on whether I run `.../b2` from the boost root directory, within the project root directory or the project test/ subdirectory, doesn't it ? How can I make the test executable find the data directory independently of where I call `.../b2` from ? I believe this is where a command-line argument would help, but accessing that from within the boost::test machinery seems tricky, to say the least.

For the boost.test part: http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boost_test/tests_org... you can pass custom arguments after the -- on the command line.

(I wouldn't mind not being able to run the tests from within the `test/` subdirectory, but I most definitely do want to run it from the project root dir, and others likely want to run it from the boost root, so there are at least two use-cases that require supporting.)

Thanks,

Stefan