Paul Giaccone wrote:

void digitise_graph_test(int argc, char* argv[]) { [...] }

boost::unit_test::test_suite* init_unit_test_suite(int argc, char* argv[]) { test -> add(BOOST_TEST_CASE(&my_test(argc, argv))); }

but this gives a compilation error:

error C2102: '&' requires l-value

test -> add( BOOST_TEST_CASE( boost::bind(my_test, argc, argv) ) ); should work.

"This function [boost::unit_test::test_suite* init_unit_test_suite ( int argc, char* argv[] )] should create and initialize top level instance of the class test_suite. The NULL pointer returned by the function is treated as a non-initialized test_suite - testing aborted and boost::exit_test_failure is returned. In other case the framework runs created instance of the class test_suite. The framework forwards command line argument specified during test invocation. It's guarantied that any framework-specific command line arguments are excluded."

I understood this to mean that the command-line arguments are passed to the test cases ("The framework forwards command line argument specified during test invocation."), but this doesn't seem to be the case.

I am not sure how did you get this conclusion, but that paragraph was discribing init_unit_test_suite, I think it's clear that framework forward CL arguments to *this* function.

So how do you pass and access command-line arguments in the test cases? I tried passing them explicitly:

void digitise_graph_test(int argc, char* argv[]) { [...] }

boost::unit_test::test_suite* init_unit_test_suite(int argc, char* argv[]) { test -> add(BOOST_TEST_CASE(&my_test(argc, argv))); }

but this gives a compilation error:

error C2102: '&' requires l-value

You could use boost:::bind to bind argc and argv with your test case. But the issue could be (I need to recheck) that argv is not promissed to be valid outside of init_unit_test_suite invocation (since the framework needs to essencially recreate the list itself). So the best would be to process all argments right in the init_unit_test_suite.

A secondary question, or rather, a polite request: Could I ask that someone edit the documentation for unit test framework, please? While is it mainly intelligible, some of it is difficult to make sense of.

Not to sound deffencive, but I did strived to make it intelligible and clear. So do you have any particular parts in mind? Maybe we could work together on making them clearer.

Apologies to Gennadiy Rozental: this isn't meant as a personal criticism nor to sound patronising, but when a developer's first language is not the language in which the documentation is to be published, it is preferable to have a speaker of that language write the documentation or at least edit it.. I can cope with the grammatical or spelling errors and am not criticising those, but the meaning is somewhat difficult to derive in some places. Documentation must be understandable to be useful, and to my mind, it is not at the moment.

And besides that any help with docs (including point to the grammatical errors) is very welcome.

Thanks.

Paul Giaccone

Regards, Gennadiy