[Product-Developers] Re: Mock testing

Martin Aspeli optilude at gmx.net
Wed Jul 2 23:23:34 UTC 2008

Hi David,

> * easy to understand
> * quick to write
> * fast to run
> Contrary to what I may have indicated in the past, I have actually 
> written products with tests, while the tests were valuable, they were 
> generally:
> * challenging to read
> * hard to write
> * slow to run
> As a result, I have tended to write fewer tests than I should on projects.
> If this thing works as advertised, I may begin to "sup" at the testing 
> "table" more often.

Heh, that can only be a good thing. :)

That said, mock testing is no silver bullet. I find that it is very 
helpful to systematically test different inputs and edge conditions. It 
also helps understand how your code works and what dependencies it has, 
because you need to understand that quite well to write effective mocks.

It is not, however, a replacement for all integration testing. It's 
quite possible to write mock tests that pass even if the code is wrong, 
and there's a danger that you end up just writing your code twice - once 
in mock syntax and once for the implementation - so that in the end 
you're not really testing anything. As with all testing, mock testing 
requires some skill and experience.

On another (non-Python) project, we use mock based testing for all 
service components and logic, unit tests running with database 
clean-down for DAO integration testing, and Selenium tests for 
end-to-end functional integration testing. Our Selenium tests tend to 
cover only the major code paths, but ensure that we haven't missed some 
wiring or forgotten a major piece of functionality. Mock-based unit 
tests then ensure that each component works to its specification.

I find this approach quite effective, and it's something we could 
consider for Plone. Selenium tests are slow to run and fairly fragile 
(because they rely on the rendered state of the page), but easy to 
record. Incidentally, I wrote collective.ploneseltest 
(http://pypi.python.org/pypi/collective.ploneseltest) a while back to 
support Selenium tests in Plone that are based on PloneTestCase setup 
and the Python Selenium remote control API (as opposed to the somewhat 
difficult-to-automate HTML table syntax).

For Zope, of course, we also have zope.testbrowser, although it can be 
hard to write testbrowser tests when you need to abstractly think about 
how the rendered Plone page is going to work. The test recorder 
obviously helps.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Product-Developers mailing list