On Wed, 12 Jan 2005 09:10:54 -0500 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:

...

In my tests, I'd rather not have #ifdef __unix all over the place. Is is possible to add a macro in the Test framework itself that can be checked (on the off chance that timeout support is expanded)?

Why would you want to ifdef it? You don't want to perform specific test unless timeout could be catched?

I do not think I was clear enough. Let's look at the example again... void infinite_loop() { // unit test framework can break infinite loops by timeout #ifdef __unix // don't have timeout on other platforms BOOST_CHECKPOINT("About to enter an infinite loop!"); while(1); #else BOOST_MESSAGE( "Timeout support is not implemented on your platform"); #endif } If I were to write a similar test, I would rather it look something like... void infinite_loop() { // unit test framework can break infinite loops by timeout #ifdef BOOST_TEST_HAS_TIMEOUT BOOST_CHECKPOINT("About to enter an infinite loop!"); while(1); #else BOOST_MESSAGE( "Timeout support is not implemented on your platform"); #endif } Also, if I may... /test/doc/examples/unit_test_example4.html appears to be wrong, as it makes reference to timeout, but the test code does not appear to use the timeout facility at all. What am I missing? Also, in the code for that test, the macro BOOST_PARAM_TEST_CASE is used. However, I can not find any documentation on how to use it. Likewise, I can not find documentation on other stuff (the only reference I can find is the one inside TestTools, but it only covers a few macros. Where are the docs for the other macros and the test_suite interface? FWIW, I am using the HTML docs from the 1.32.0 disctibution. Thanks!

(I would MUCH rather have a searchable document, with appropriate TOC -- even a printed version is much easier for me to navigate than a billion non-indexed links -- now watch someone tell me how easy it would be to create a searchable index of boost docs -- I'd really like that ;-).

PDF is my todo list. Gennadiy

On Wed, 12 Jan 2005 12:46:42 -0500 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:

Example uses ifdef because:

1. It used to demonstrate that timeout support is not supported everywhere 2. We know for sure it will hang if run on a system that does not support timeout

Right. I understand.

You as a user shouldn't in general expect it and if it does hang and your system doesn't support timeout you will have to interrupt it yourself. The only reason to use ifdef is the case when you are doing portable development and willing to ignore possible infinite loop on some configurations for the sake of ability to run a test as a part of regression suite (without human intervention). Is it really the case?

Yes, I know, and understand all you are saying here. Maybe trying to be complete has hidden what I am really asking. What I am requesting is that Boost.Test supply a macro that can be used instead of me, the dumb user, having to know if the internals of Boost.Test support my platform. I would like to do something like... #ifdef #BOOST_TEST_Some_Macro_Telling_Me_If_Timeout_Is_Supported_On_My_Platform rather than doing... #ifdef __unix Since the Boost headers already have figured out my platform, and Boost.Test is the one that knows the support it provides. Thanks!

On Thu, 13 Jan 2005 09:40:57 -0500 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:

Ok I will provide such macros.

Thanks. BTW, for the record, I have just started using Boost.Test (as the recent questions imply), and I am quite relieved at how easy the framework is to use. Of course, the hard part is writing the tests, but the main reason most people do not write lots of automated tests is that it is difficult to do so without a framework to manage it all. I have found it to be very easy to understand, and it also looks like it will be easy to use in pure C projects as well. Thanks!