I know that test should drive the code not vice versa but sometimes you still have to write tests post factum. Here is a related anti-pattern I have noticed to be using quite often.
Lets say there is a service class that does nothing else but coordinates calls to different DAOs. How do you test it?
Here is the way I have done it many times. As I said you have the service class that is supposed to work. As test execution will be aborted immediately when the first assertion fails I add behavior to only the first call of my first mock. If that passes then I add the next one and so one. At the end of test I verify that all methods required were actually called. Later I add variations with different input values and different behavior of mocks.
Now the problem with this kind of approach is that it doesn't test anything but the most obvious. Yes it forces me to rethink the logic that this service has implemented but I have a strong bias to believing that current implementation works correctly - I'm in the mode of trying to get the test pass.
But is there any better solution to this situation? I haven't found any so far - if code drives tests then you loose quite much of the power of unit tests.