I am using the test-framework to test a main program. That is, the main program has various flags, and I test that it properly responds to them - the bulk of the logic resides in pure libraries that are tested elsewhere.
To test the program, I use hDuplicate tricks to redirect stdout/stderr/etc. to files, invoke the main program, redirect them back and verify the results.
The problem is that the test framework is executing at a separate thread, and also writes to stdout/stderr. This (sometimes) corrupts the program's output - there is only one global stdout/stderr and when I redirect it, it applies to the tested program as well as for the test framework.
Initially I thought that using -j 1 would solve the problem. However, it doesn't; -j 1 only restricts the number of test worker threads, but the test framework thread always exists.
Possible solutions would be:
Perhaps add an option to test-framework to write to the file descriptor n?
Then you can invoke it from a shell as ./mytest --out-fd 3 3>&2.
./mytest --out-fd 3 3>&2
feuerbach's commet made me realize there's a simpler solution...
When test-framework starts executing, it should first hDuplicate stdout/stderr. All I/O should be done through the duplicated handles and not via the global stdout/stderr. This way, if tested code does hDuplicateTo stdout/stderr, the test-framework I/O will continue to be sent to the original file, while the tested code will behave as expected.
AFAIR test-framework already funnels all I/O to go through some specialized functions, so the effect on the code should be pretty localized...
I didn't resolve the issue as such; I modified my application so it redirected all stdout/stderr output to files so I could invoke it directly from the test framework. This works reasonably well for me, and is thread safe - it is arguably "the right thing to do".