LOL. This was too funny not to share. I had a unittest failure in a project that I'm working on, and dub ended up just printing out
Program exited with code 1 rather than printing out the actual failures, which was not exactly useful. And I thought that dub must have a bug, so I started trying to see if anyone else had seen a similar problem and which version of dub the problems started in (since I was sure that I'd see proper test failure output from dub previously), and finally I figured out that no, dub didn't have a bug. Rather, it looked like dmd or druntime did, because the problem happened even without dub (though without dub, _nothing_ was printed, since the "Progam exited with code 1" is a dub thing, whereas normally; the D program that failed the unit tests just exits with a code of 1 without printing anything), and it turned out that whether or not I saw the AssertErrors from a test failure depended on where in the file the failing test was, which definitely made it sound like a dmd bug. So, in order to report the bug, I used dustmite to reduce the code and managed to reduce it quite a bit (though not as much as I might like), and then I manually reduced it further. And ultimately, this is basically what I ended up with import core.sys.posix.unistd; unittest { close(2); assert("hello" == "7"); } void main() { } My faulty code had managed to close stderr, which made it impossible for druntime to print out the assertion failure. :) So, I get to feel like a bit of an idiot over the whole thing, but it definitely made me laugh when I figured out what I'd managed to do. However, it does highlight the fact that if you just look at the output of running the unit tests and not the exit code, you might think that your tests succeeded when they actually failed. But fortunately, that's not terribly likely (much as I managed to do it), and if you're using dub, it does check the exit code. - Jonathan M Davis