A test suite may run for a long time and bailing out at first failure is a very stupid thing to do. It may be nice to have it as an option but not the only way of doing it.
Even a humble test suite might take 5 minutes to run, going to grab some coffee and coming back to see the first test fail would be a bad thing. A big test suite might take hours on a CI server, having it fail on the first test would be a major waste of time.
And with a modern distributed version control, there's no reason why you shouldn't commit code (not to the master branch!) that doesn't pass tests. To share it with your team mates or push the code to be tested on a CI server, for example.
or you are probably doing functional testing in your units.
Though I like your style, very simple, and simple is good. The state is binary, tests are passing or they are not. Unfortunately in this particular reality the added complexity of knowing all broken tests can prove very useful.
If I'm using fuzzing to run thousands of tests, and all the ones whose seed led to the same specific bit pattern are failing, that's particularly useful information. I found a particularly subtle bug in heatshrink (https://github.com/atomicobject/heatshrink) that way, but a single failing test would have looked like noise.
just the short of thing a QA dev would do to keep his job.
i kid. kid. It is nice, but overkill in my humble opinion. Failing on the first error for unittest is a feature. because you are not supposed to even commit it if it is failing, so no need to fancy graphics and reports. It either passed, or not.