Why you should do assertions the way I don't want to do them . . .

I have heard people say things like "In unit tests, each test should pass or fail for exactly one reason."  Practically, this means there should only be one assertion per method.  Yeah, right.  I've done the math.  That's a friggin' big pile of tests when you could have 20 assertions in one method!  And who wants to think up that many good test names (because runtest0 will only go so far)?  Am I right?

So, I coded a test like this, because there were multiple assertion validations with one condition, E.G.,

void testSomething()
{
 stage(data);
 assert(reason1);
 assert(reason2);
 ...
}

That worked fine, and met my goal of being green and saving the planet by reducing the number of carbon-footprint bearing test methods.  Then I refactored something that I knew would effect this code.  Unfortunately, I had to do a lot of creative commenting just to get the crap fixed because the entire test wouldn't pass until all the assertions passed.  What a pain.

So, I guess there is something to that after all . . .