I use the phrase in the title usually to refer to using mock objects in a useless way (mocking ADO.Net or Active Directory or calls to any API that you don’t understand). When you’re choosing whether to write a small integration test or a mocked test, just think what would give you the actual value. If the mocked test doesn’t actually prove that whatever you’re doing works, then it isn’t useful.
Today we got a little reminder about this rule. By accretion, we are building a little Fluent Interface that uses lambda tricks to configure NHibernate mappings without having to expose my tender eyes to angle bracket hell. Behind the scenes, it still generates good old fashioned hbm Xml, but at least I don’t have to see it. Today we hit our first case of a somewhat common mapping scenario. We had a unit test that specified that the Fluent Interface built the Xml exactly the way we intended it to for this scenario, but as soon as we tried to use it, NHibernate threw a 50 line stacktrace exception. Lesson (re)learned here, we probably need to skip the intermediate unit test to worry about the intended effect of saving the object. The Xml was only an intermediate deliverable, and not the real goal.