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.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
