--- In testdrivendevelopment@yahoogroups.com, Steve Freeman
<steve@m...> wrote:

<snip/>

> Our experience is that TDD using mocks encourages interface
discovery,
> so mocks should drive the type system but not necessarily its
> implementation.

I think this nicely illustrates the nomenclature issue. Are you
saying that TDD using "not real" objects encourage interface
discovery? Or do you mean that TDD with mock objects that are
self-validating and fail fast provided that encouragement?

The fact is that the term "mock object" is broadly used in a more
generic way. I suppose there is no harm in using it in a more
restricted way in a certain context where everyone understands
that more restricted usage. Otoh, it's easy to make bad
assumptions about what everyone understands. And using it more
broadly is only confusing.

When it comes right down to it, "mock object" is a poor choice
for a specialized meaning. The words are suggestive of the
broader meaning. A generally knowledgible programmer upon first
hearing the term might well assume that broader meaning and never
ask for clarification. That would lead to the very worst form of
miscommunication in which everyone belives they are talking about
the same thing when in fact they are not.


Please, let's not make it more difficult for developers to learn
about TDD and how to do it effectively. Use terms that
communicate to a broader audience.

Kiel Hodges