Testing on master is broken when writing to stdout?

Help
1

When I run ‘zig build test’ it hangs on the following:

test "unbuffered writer" {
    // NOTE: can't be a const
    var stdoutWriter = std.fs.File.stdout().writer(&.{});

    try stdoutWriter.interface.print(("\nUnbuffered writer.\n"), .{});
}
1 Like
2

you can’t write to stdout from a test, stdout is used by the build runner to communicate with the test runner

3

Ah yes, good ol’ #15091. Don’t expect that to change.

I think the general premise of “don’t write to stdout while testing” is ok, I don’t love the behavior where it hangs in a deadlock instead of, well, doing something else.

In any case, if you need to do it anyway, for some reason, ZTAP† permits stdout printing (at the risk of interfering with the protocol). Or you can just use it as a basis for your own test runner, they’re easy to write.

Welcome to Ziggit!

† This won’t build under Zig 0.15 yet, I’m just getting around to overhauling all of that. Should within a couple of days.

4

Ah thanks.

I swear it was working for me up to a few days ago but it seems to be an old issue.

Edit: I used to write to stderr using std.debug.print but recently changed. That seems to have caused my issue.

5

I know how to implement that issue now. When spawning the test runner the build runner can make the protocol pipe be fd 3 instead of 1, and go ahead and read data from 1 (stdout), but fail, print the offensive text and say unexpected data was printed

5 Likes
6

Yes, that seems like a better approach than in-band signalling.

It would be nice if the test runner could at least be configured to just drain stdin into the bit-bucket though. I’d guess that the #1 reason for a test trying to write to stdout is a bug, and it should be doing something else instead. So surfacing the error is better than silently ignoring it, as the default behavior.

But next after that would be testing something which usually writes to stdout while doing something else, surely. Granted that there’s always a way to add extra logic so that it cooperates with the test machinery, perhaps with virtuous results.

Still would be a nice affordance to be able to redirect it to the bit bucket instead, on the premise that the user is the one who determines what program behavior passes and fails a test suite.

This is now done.

1 Like