Re: [Boost-users] [unit_test_framework] checkpoints for BOOST_CHECK*?
rozelak@volny.cz wrote:
rozelak@volny.cz wrote:
Is there a way how to achieve what I am looking for?
> Use BOOST_TEST_MESSAGE and set log level to message
Yes, I have read about this option and it works - thank you. I consider
it as not perfect, but working solution.
and used during check failure printing as well (as has been suggested in the example in my first post). I don't know boost source in depth, but it seems
However, I want to ask, if the idea of checkpoints could be generalised that BOOST_TEST_CHECKPOINT
just calls boost::unit_test::unit_test_log.set_checkpoint(...),
> > which stores the checkpoint info in unit_test_log (which is supposed to be singleton). Would, therefore, be possible to print the checkpoint stored also when test failure is printed? May I be helpfull somehow to do this?
Or is it against the idea of the checkpoints?
I think the issue is that BOOST_CHECK and friends set a checkpoint.
I see, you are right. It is set by BOOST_TEST_PASSPOINT() macro. Well, do you think, that it would be beneficial to define new macro, e.g. BOOST_TEST_FAILRECORD (please suggest a better name, if you have one)? The macro would be implemented in the way very similar to BOOST_TEST_CHECKPOINT, but the data "recorded" by the macro would be printed only when a testcase fails or an unexpected exception occurs. It also has the advantage, that when not used, it does not affect the current behaviour of boost. Is there a change to accept it in the boost test framework, if I try to implement it? Thank you for suggestions/comments, Dan
rozelak@volny.cz wrote:
Is there a change to accept it in the boost test framework, if I try to implement it?
1. I forgot to mention that you can use BOOST_CHECK_MESSAGE and record whatever you want there. 2. I do not see how this is better than BOOST_TEST_MESSAGE approach. You run your test either with log level set to message all the time or run it with default log level, but as soon as it fails you can rerun it with lower log level and see all the details. What do you find lacking in this approach? Gennadiy
rozelak@volny.cz wrote:
Is there a change to accept it in the boost test framework, if I try
to implement it?
1. I forgot to mention that you can use BOOST_CHECK_MESSAGE and record whatever you want there.
Yes, I know. But I cannot use it in form BOOST_CHECK_EQUAL_MESSAGE. If such a for of CHECK_EQUAL would be there, it is also what I could use for what I need. Imagine the following: 1) BOOST_CHECK_MESSAGE(4 == 5, "are you normal?"); 2) BOOST_CHECK_EQUAL(4, 5); 1) does not print expected and actual value, which I would like to know. It just prints something like: Test.cpp(150): error in "JustExample": are you normal? 2) on the contrary cannot print a message. What I looking for is to have the join of the two. Something like: Test.cpp(151): error in "JustExample": check 4 == 5 failed [4 != 5]: are you normal?
2. I do not see how this is better than BOOST_TEST_MESSAGE approach. You run your test either with log level set to message all the time or run it with default log level, but as soon as it fails
you can rerun it with lower log level and see all the details. What do you find lacking in this approach?
There are extensive tests started automatically on regular basis required, and some random permutations are used in some of the special tests (we can discuss about meaningfulness of it, but it is the requirement ...). So, when BOOST_TEST_MESSAGE is used, it either prints everything or nothing (depending on the log level set). It is much more convenient to have only failures included in test results (as boost already does it now, and even I don't care about conditions not resulting in test failure ...). However, I need to have detailed test conditions included within the failure message as well (and they may be quite complex ;-)). That's my motivation. But you are right. It may be easier to create BOOST_TEST_EQUAL_MESSAGE macro (and those not supporting messages as well), than to introduce new kind of "checkpoint". Thank you again. Best regards, Dan
There are extensive tests started automatically on regular basis required, and some random permutations are used in some of the special tests (we can discuss about meaningfulness of it, but it is the requirement ...). So, when BOOST_TEST_MESSAGE is used, it either prints everything or nothing (depending on the log level set). It is much more convenient to have only failures included in test results (as boost already does it now, and even I don't care about conditions not resulting in test failure ...). However, I need to have detailed test conditions included within the failure message as well (and they may be quite complex ). That's my motivation.
If these are automated tests: 1. Why do you care about content of the output at all. I mean just use log_level=message and store all the logs. You'll review them if any failures will actually happen. 2. You can use XML format and present it to your screen in a way you prefer. For example you'll skip messages if test case has no failures and show them if it is. Gennadiy
writes: There are extensive tests started automatically on regular basis required, and some random permutations are used in some of the special tests (we can discuss about meaningfulness of it, but it is the requirement ...). So, when BOOST_TEST_MESSAGE is used, it either prints everything or nothing (depending on the log level set). It is much more convenient to have only failures included in test results (as boost already does it now, and even I don't care about conditions not resulting in test failure ...). However, I need to have detailed test conditions included within the failure message as well (and they may be quite complex). That's my motivation.
If these are automated tests:
1. Why do you care about content of the output at all. I mean just use log_level=message and store all the logs. You'll review them if any failures will actually happen.
Yes. But imagine that dozens of lines are printed (or stored into a log)and you have to look through all the messages. OK, it is not a big problem, it is rather uncomfortable. I believe that having the possibility of printing user-defined messages on test failures will even increase the comfort of boost-test framework usage, with no high cost to pay to implement this. And actually, it is already possible with BOOST_CHECK_MESSAGE.
2. You can use XML format and present it to your screen in a way you prefer. For example you'll skip messages if test case has no failures and show them if it is.
Right again. But it will not work when the test suite is started from command line where it is more convenient to use simple format (see 1.). Bu may I have a question as well? Why do you refuse the extension of BOOST_WARN|CHECK|REQUIRE_* macro by user-defined massage? It seems to me as a natural extension of the macros (it is already possible with BOOST_CHECK_MESSAGE), while it by no means affects the existing interface. Is it so difficult to implement it? Is there a general resistance against interface extension? I am really sorry, but can't see a reason why not to simplify into one command doing itself effectively what you suggest to workaround (by the setting of log level, XML filtering, etc?). I offer my try to code it and send a patch for revision to you, if someone could provide slight guidance to me. Thank you very much. Best regards, Dan.
rozelak@volny.cz wrote:
Bu may I have a question as well? Why do you refuse the extension of BOOST_WARN|CHECK|REQUIRE_* macro by user-defined massage? It seems to me as a natural extension of the macros (it is already possible with BOOST_CHECK_MESSAGE), while it by no means affects the existing interface. Is it so difficult to implement it? Is there a general resistance against interface extension?
There are tons of these. Presenting yet another set of 30 or so macros with very limited advantage does not seem warranted to me. Gennadiy
Simon Pickles
Simon Pickles wrote:
Simon Pickles wrote:
Hi
I am using the Unit Test Framework to test my use of boost.python. I am using a global fixture to initialize the python intepreter a single time (rather than before each test).
My problem is I would like to use the Python initialising class in my tests, and I can't figure out how to do this. I don't want to use normal fixtures since each test would call initialize the interpreter, causing problems.
Boost.Test does not provide means to do this directly. You can alsays mimic some kind of singleton though: struct GlobalFixure { GlobalFixure*& instance() { static GlobalFixure* s_inst = 0; return s_inst; } GlobalFixure() { instance() = this; ... } }; ... GlobalFixure::instance().m_member.do_something(); ################# Is this approach used as a global fixture or a test fixture? Thanks Simon
participants (3)
-
Gennadiy Rozental -
rozelak＠volny.cz -
Simon Pickles