Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Reusing stdout/stderr #19

Closed
orenbenkiki opened this Issue · 4 comments

3 participants

@orenbenkiki

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:

  • Allow for -j 0 (or something like that) that insists on everything happening in one thread - this may impact some functionality (recovering from certain nasty faults in the tested code), but that would be OK.
  • Avoiding doing stdout/stderr IO when a test is running in some worker thread (not certain how practical that would be).
  • Something else?

Thanks,

Oren Ben-Kiki

@feuerbach

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.

@orenbenkiki

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...

@batterseapower
@orenbenkiki

Hi Max,

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".

Thanks,

Oren Ben-Kiki

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.