[test] Possible race condition? (minor)

Boost unit test framework seems to have a race condition in its output. When I run my test program from a shell, I get this output: paulg@klingon 120% ./CubicTest Running 8 test cases... *** No errors detected paulg@klingon 121% ./CubicTest>/dev/null *** No errors detected Note that the second call above, redirecting output to /dev/null, suggests to me that "Running 8 test cases..." goes to standard out and "*** No errors detected" goes to standard error. Because standard error is unbuffered, this can mean that the messages are output in the reverse order. This is the case when I run my program from Eclipse (under Linux), and, in general, will happen if the tests run faster than the time it takes for the buffer to flush to the output. This suggests one of the following is required: * Flush standard out before running the tests * Send all output to the same stream (but this is not recommended, as this would break the defined behaviour of test suites) * Synchronise the two streams by some other means It's possible that Eclipse displays the output to standard error before the output from standard out, but such behaviour isn't seen when executing a makefile, so it seems likely there there is a race condition in Boost unit test framework. Paul

"Paul Giaccone"
Boost unit test framework seems to have a race condition in its output.
When I run my test program from a shell, I get this output:
paulg@klingon 120% ./CubicTest Running 8 test cases...
*** No errors detected paulg@klingon 121% ./CubicTest>/dev/null
*** No errors detected
Note that the second call above, redirecting output to /dev/null, suggests to me that "Running 8 test cases..." goes to standard out and "*** No errors detected" goes to standard error.
Because standard error is unbuffered, this can mean that the messages are output in the reverse order. This is the case when I run my program from Eclipse (under Linux), and, in general, will happen if the tests run faster than the time it takes for the buffer to flush to the output.
Ok. I've added flush statement at the end of testing for log stream. This with happened before report is started. Gennadiy
participants (2)
-
Gennadiy Rozental
-
Paul Giaccone