[TIP] Functional Testing of Desktop Applications

[Grig Gheorghiu]

--- Nate Lowrie <solodex2151 at gmail.com> wrote:

> On 3/5/07, Grig Gheorghiu <grig at gheorghiu.net> wrote:
> > I think that mocking actually speeds things up tremendously, while
> also
> > complicating them....But for a project like PyPy, which does lots
> of
> > backend stuff, I would think mocking would be beneficial in many
> cases
> > -- so that functionality gets tested in isolation. It would be
> > interesting to know whether the PyPy guys actually do any mocking
> in
> > their testing.
> 
> I would agree.  It also tends to minimize the number of times a code
> path is tested.  I think that it is absolutely vital for all of the
> slow, unpredictable, and sometimes persistant connections like
> databases, socket, etc.
> 
> However, I will caution you in that I think you are combining mock
> objects with the other fake objects like test stubs and test spies.
> Even though stubbing is done with the python mock object frameworks,
> it is not mocking.  The difference is that stubbing can do state
> verification while mock objects can do only verification.  Yes you
> can
> put stubbing in a mock object, but checking behavior and states
> should
> be 2 different tests.
> 

You're right -- I was using mocking in a loose fashion, meaning both
mocking per se (which to me means setting expectations on what methods
get called in what order, how many times and with what parameters), and
stubbing, test spies, etc. I personally don't put a very high value in
mocking expectations. I find that stubbing and being able to simulate
exceptions cover 90% of my needs. But it so happens that mocking
frameworks such as python-mock or PyMock offer a lot of nice features
out of the box even if you only need stubbing.

Grig