[TIP] Functional Testing of Desktop Applications

[Grig Gheorghiu]

--- Michael Foord <fuzzyman at voidspace.org.uk> wrote:

> This leads us into a bit of a debate about how much to mock out in
> our 
> unit tests. The most extreme testing doctrine says that you should
> mock 
> out *all* your dependencies when testing a unit - even dependencies 
> within the same object (if you are testing method 'a' and it contains
> a 
> call to function or method 'b' you should mock 'b').

I think this is a very extreme view of mocking. It would drive you
crazy very fast if you started mocking dependencies within the same
class.

My view is that you should mock only when your code depends on external
interfaces that generate random results (Web servers, XML-RPC servers,
etc.). Generally speaking, at the I/O boundaries of your application,
or when you deal with libraries/3rd party code over which you have no
control. 

It's also useful to mock the database layer, for several reasons:

1) speed 
2) consistency in getting back the results you need
3) simulating exceptions

You can also achieve 1) and 2) with small test databases (in-memory or
not). But it's very hard to achieve 3) without mocking.


> 
> When you have a short function that has several dependencies this can
> 
> make writing the tests a real chore. It *also* means that you don't 
> catch errors at a higher level - where you mock you test adequately
> what 
> you *think* the wiring between your units is doing, but your mental 
> model may be just as buggy as your code.

You're right, if you overuse mocking, the test code can quickly get out
of sync with the 'production' code.

> 
> I'd be reluctant to add an *extra* level of testing (we already have
> a 
> three-to-one ratio between test and production code). We're moving 
> towards a less extreme mocking policy I think though, making sure we 
> always have some higher level tests that exercise units together and
> not 
> just in isolation.
> 

I think this is a good strategy.

Grig