Coming onto you like the bastard brother of Assertion Roulette, i propose Assertion Monolith - when many assertions are bundled into one. For example, a load of sample data structures, followed by a method call and then something like this:

$this->assertIdentical($bigFatDataStruct, $bigFatExpectedOutputDataStruct);

Assertion Monolith is a sure sign that the test followed the implementation. Coding this way round is like showering with your clothes on, emerging with dripping garments, hanging them out to dry and spending the rest of the day walking around town naked.

No really, it is.

A monolithic assertion can contain many sub-assertions within it, but none are explicitly referred to or documented. Go through 10-20 of these assertions, and suddenly you've got a whole load of unmaintainable tests. When one monolith assertion breaks, you'll have to manually break it down into it's component assertions. Most importantly though, a monolith assertion tells you next to nothing about the code it's testing. This is an important role for tests.

So, what i'm saying is, if you're gonna go the testing route, do it incrementally, as is the TDD way.

The Test Smells section at the XUnitPatterns site is pretty great. No doubt Mr. Beck would approve.