[TIP] Mock objects in testing object composition?
kumar.mcmillan at gmail.com
Fri May 18 12:00:43 PDT 2007
On 5/17/07, Benji York <benji at benjiyork.com> wrote:
> Kumar McMillan wrote:
> > On 4/24/07, Julius Lucks <lucks at fas.harvard.edu> wrote:
> >> Many thanks Benji and Paul.
> >> Looks like simpler is better. So when are mock objects useful?
> > in my experience, mock objects are useful mostly for depending on some
> > kind of "external" resource.
> Purists would probably call those "stubs" instead of "mocks", but I see
> what you're saying.
I'm with Michael, I really think there should be one name for the two.
Can we just call them stamocks? or something. In this case, the FTP
object only stands in for the interface and does not assert that it
got the correct inputs (so it's a stub). However, what I left out of
the intercepted service explanation is that there are some tests where
the fake service asserts that it got a proper request, so it is by
definition a mock. I think this detail is so minute that it would
clear up confusion if there was one name for such an object!
Furthermore, this introspection test came about later on when I was
fixing a bug in how requests were built, iirc. At first it was by
definition only a stub.
There, now If someone can think of a name better than stamock I am
totally going to make a wikipedia page with a big notice that says
"not approved by Martin Fowler" :)
> A technique I like to use in those situations is to write a
> parameterized test and apply the same test twice. Once in an
> environment where the "real" thing is used and once where the "stub" is
> used (with the "real" test running only in a non-developer-blocking way,
> like buildbot (except when explicitly requested)).
> That gives you the best of both words: you can test against the real
> thing when you've made the effort of setting up the environment, and you
> can be reasonably sure that your stubbed out environment is realistic
> enough when not.
I also find this to be an excellent strategy. Our FTP object is
exactly this. A separate builder in buildbot will flip a switch (via
bash environment var) that makes all ftp tests go through the live
servers. However, the tests are configured so that they do all work
in a temp dir on the remote FTP server. This is a great test because
it tests that the real ftplib module is used correctly and that the
remote FTP servers are still alive and disk quotas are still good,
The fake service works like this too (hits a staged version of the
real service when a switch is flipped), but only sometimes. For
example, when testing in the "mock" style, where the fake service
asserts that it got a properly formed request, such a test is only
possible in mock form.
> Benji York
More information about the testing-in-python