
Le 16/12/2016 à 16:31, Florian Lindner a écrit :
Am 14.12.2016 um 17:25 schrieb Raffi Enficiaud:
Le 14/12/2016 à 11:20, Florian Lindner a écrit :
Am 12.12.2016 um 09:24 schrieb Florian Lindner:
Hello,
I need to conditionally decativate tests and use a custom decorator for that, like that:
virtual void apply(bt::test_unit& tu) { [...] if (std::find(_ranks.begin(), _ranks.end(), rank) == _ranks.end()) { std::cout << rank << " Disable, because of rank, test: " << tu.full_name() << std::endl; tu.p_default_status.value = bt::test_unit::RS_DISABLED; return; } }
(i'm happy to provide full source code, if anyone is interested) As you can see it's deativated on some MPI ranks only.
However, if a user uses -t "testname" it is activated again.
Is there a way to really deactivate the test? Or delete it from the test tree?
Seems to be next to impossible:
test_suite.remove(tu.p_id); has no effect.
bt::framework::deregister_test_unit(&tu); causes a SIGSEGV within boost.
tu.p_default_status.value = bt::test_unit::RS_DISABLED; as I said above, only disables if not enabled otherwise.
You cannot do that: - inside a precondition, if you start modifying the test tree, this would lead to hazardous behaviour - the apply is not meant to be used. The public api is the one described here: http://www.boost.org/doc/libs/1_62_0/libs/test/doc/html/boost_test/tests_org...
Any ideas anyone to completely disable / delete a test case from within a decorator?
[snip]
We have a lot of tests, and there are many which should just run on one rank as well as many that run on multiple ranks, testing parallelized scenarios. I would REALLY like to go with automatic test registration, instead of declaring so many tests in the init function.
Ok
[snip]
I understand your design rationale. Please try to understand mine. The precondition decorator does what I need, except that is flags the test as failed if unmet. I just require a method to skip / delete / do not execute a test if a certain runtime condition is met and do NOT flag this test as failed.
Ok, this is a bug in the backlog: https://svn.boost.org/trac/boost/ticket/12095 I believe solving this would satisfy your requirements. Best, Raffi