When to use mocks in unit tests?

[Tom Whittaker]

I have a development manager who wants us to mock almost every single
component our software change interacts with because he insists that
we are suppose to completely isolate our unit test from other
components, which is what he calls a unit test.

We keep telling him that is not how to write unit tests, but he is the
manager, and so we've been doing it this way.

For example, I agree with the following web page's "Reasons for use"
of mocks.

http://en.wikipedia.org/wiki/Mock_object

Does anyone have the argument that supports the extreme position our
manager is taking? Or, a good book or paper that argues against this
extreme?

From what I've been seeing, it has created poorer quality software
because we are actually not finding bugs that use our real databases
and external web services until very late in the process. We just had
a feature freeze date, and we found a few major problems that day
largely because everyone was using mocks, and the mocked systems did
not behave the way our mocks did, and the higher level functional
tests created by QA missed a few things that a normal unit test would
of caught had we not been using mocks for everything.

[Bob Gong]

Tom,

Do you have a integration test system built in your project?

In my opinion, unit test shall be isolated from other components as
possible, and integration test shall integrate real components as
possible. They are covering different levels issues.

Are you using Cmockery to mock function or write mock function by
yourself?
Cmockery framework enable you to define mocked system behavior in your
test, so you always can test unit by intent. If mocks behave
differently as real component did, I think the mocks behaviors shall
be fixed.

Regards,
-Bob