[nabbe23]

Well-written breaking tests represent something changing in a code base. You can be intentional about breaking a test, but then at least you can be very explicit about what you are changing.

Have seen all to many times I've broken a unit test in a code base that I did not intend to break, just to have an aha moment that I would have introduced a bug had that test not been present.

Unit tests are a trade off between development speed and stability (putting aside other factors, such as integration tests, etc). In large corporate settings, that stability could mean millions of dollars saved per bug.

That example you provided is a poor one and not really consistent with your point that unit tests are useless - the point is being made that that specific test of UserResource is useless, which I also agree with. Testing at the Resource level via integration test and Service level via unit test is probably sufficient.

[Joel_Mckay]

Especially true if you get emergent side-effects from non-obvious shared state dependencies in large projects.

Nightmares... =)

[nabbe23]

Yes sir :)

And pragmatically - this always happens at some point. Something something about deadlines and need to get this out yesterday.