Thought about it, and I don't agree that this is a good idea, outside of a few special cases. Test coverage from failing tests - I can't see being concerned ab

Thought about it, and I don't agree that this is a good idea, outside of a few special cases. Test coverage from failing tests - I can't see being concerned about the coverage of a suite that isn't completely passing. If you have failing tests, you have bigger problems than your test coverage figures. As for the test continuing, if an early assertion failed, then your state is unknown and can't be trusted. To do this, you'd need to spend a lot of time for every non-terminating assertion reasoning about all of the possible states your system could have that would have caused that assertion to fail, and come up with reasonable things to do in the rest of the test for all of them. I can't see much value in this effort specifically. Better to let it blow up and try to fix whatever caused the first bad assertion to fail. I think it might be useful to strive for one assertion per test though. Then, you can get a better idea of what's failing and where by how many tests fail. Sounds a lot like the benefit the author cited. Key difference though - you aren't reasoning about the state of your application after a test failure. The other assertions set up their own state from scratch after the other test's state setup is torn down, so it's either as they expect, or they can blow up too.