Working on Plone projects our team tries to achieve full test coverage at least for important products. The kind of tests we write are unit tests, functional tests and integration tests. (Also stress-tests, but those aren't in the scope of this question). The goal is two fold at least: to facilitate upgrades and to catch bugs (sometimes it even happens in the process of writing tests).
However, Plone/Zope is a complex system, and with years of experience I've noticed, that test strategy should be re-thought. First of all, unit tests, which often require to use a lot of mocking, are not that (cost)efficient. They are mostly easy and beneficial when some core, logic-heavy functionality is being written, like pure Python modules, which have negligible couplings with Plone/Zope, databases, etc. I rarely seen unit-tests catching any bugs at all, except while writing them.
So, when doing the usual thing (writing views/portlets/viewlets), from my experience, it's much more efficient to write functional and integration tests. The rationale of it is that in case Plone/Zope changes (in an upgrade) we can catch the mishaps in our code. Views usually do not have a lot of "algorithmic" logic, they glue together several data sources (like catalog queries), maybe with some form handling and preprocessing for templates. It is quite often views call one or more tools to do some routine job (like getting navigation tree or looking up site root). Mocking it all seems unwise. For example, sometimes Plone/Zope changes some default to another type and all those mocked tests happily continue to work while code fails in the real instance.
Functional/Integration tests may be at times fragile (HTML can change), but they are cheaper to produce too. They provide basic coverage, and trigger alarms when underlying system changes. Spotting the source of mishap is usually not an issue. (update: Wrong: spotting where integration test fails can be a big issue, but our code's unit tests are usually of no help.)
The question is, am I overlooking something of importance confining unittesting to functions and classes, which do not require mocking the environment heavily and are instead "purely" logic-heavy? I can't find any justification for writing unit-test "first", or even at all, for every piece of code in Plone/Zope (I do not mean the core of the system, just our own additions for our clients).
To make the question less opinion based, are there other reasons, I have not mentioned or tackled above, which necessiate to consider writing more unit tests (and less integration tests) in a situation when code heavily depends on a complex (and somewhat hairy) framework, and code serves more as a glue for framework's subsystems?
