Re: [Boost-users] [unit test framework] Command-line arguments; documentation

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-10-17 09:21:06

> "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