Add a way to identify the executable as a boost-test

[jan.wilmans@…]

I propose to standardise a command-line option to identify the executable as a certain kind of test: I will propose this to boost.test and google.test as well. My personal usecase is the identification of tests for BoostTestUi (the name is somewhat misleading, it is a test-runner for google-, boost-, catch- and nunit- tests, see github/BoostTestUi.)

Currently this requires re-compilation of the test with a special header, I would like to prevent the need for that.

--test-runner-identification framework: boost.test version: x.x

--test-runner-identification framework: google.test version: x.x

--test-runner-identification framework: catch.test version: x.x

This will allow test-runners to identify the test-framework used to build the test. That way the test-runners can know what command-line parameters are available to do things like:

• list all the tests
• run specific tests

finally, to let the user attach a debugger to the test this kind of code could added in the main(): (for catch that may already exist, I did not check)

notice that this option can have any name, we need only 1 standardised option --test-runner-identification, because once we know what we're dealing with, we can just use the respective command-line options.

if (arg == "--gui-wait") {

std::cout << "#waiting" << std::endl; std::getchar();

}

[Raffi Enficiaud]

Hi,

Thanks for the proposal. As I understand it, you do not want to just use the runtime switch --version and parse the result instead. Is that correct?

[anonymous]

well, this would be ok, if catch and googletest would also have a simular --version flag, however (oddly) they do not.

[Jan Wilmans <janwilmans@…>]

And even if they had, a drawback of that is, that I would rely on the --version message always staying the same (something I would not want to force on anyone).

The rationale to require a new standardized/shared command-line parameter is that is it would never change and because the version number is included any other changes in the command-line handling can be dealt with by the test-runner without breaking support for earlier versions.

[Jan Wilmans <janwilmans@…>]

I have been asked to write a proposal. I can't create external links here, search for 'LibIdentify' on github.com, you should find janwilmans/LibIdentify