Re: Circular dependency hell.

Hi,

On 04/17/2010 06:34 AM, Martin Aspeli wrote:
> Hi Lennart&  co,
>
> On 17 April 2010 02:38, Lennart Regebro<[email protected]>  wrote:
>> On Fri, Apr 16, 2010 at 19:53, Jonathan Lange<[email protected]>  wrote:
>>> As the author of one of those other testrunners, I can tell you that
>>> if you do this you'll find that your number one biggest problem is
>>> getting layers to work.
>>
>> Ah, right, layers are in zope.testing too. To actually get widespread
>> movement from zope.testing we would have to make some other layer
>> support. Hm...
>
> As you may know, I've been working on plone.testing. This is mainly to
> make it easier for people working on Plone packages to write "good"
> tests (and a lot of it is just about patterns, rather than code), but
> in fact it doesn't depend on Plone (and only soft-depends on Zope 2).
> I'm certainly hoping to use it for my "plain Zope 3/Toolkit" packages
> in the future.
>
> plone.testing makes very heavy use of layers. I think layers are a
> great feature, when done properly, and I haven't seen any better
> approach. The setUpClass/setUpModule stuff in unittest2 is nice, but
> doesn't really solve the same problem. For integration testing with
> something as complex as Zope 2 (or, arguably, the ZODB, various bits
> of the ZTK, and so on) layers allow "us" the framework authors to make
> life much easier for those people who are not experts in the
> framework.
>
> Anyway, a few high level observations:
>
>   - In neither plone.testing (apart from its own tests), nor in code
> that uses it, would I imagine actually depending on zope.testing via
> an import. We use unittest(2) and doctest from the standard library.
>
>   - We do depend on a zope.testing-compatible test runner, in that we
> expect layers to work. In reality, we depend on zc.recipe.testrunner,
> though I would *love* to be able to do 'python setup.py test' as well
> (and have that execute tests with layers). I have no idea how that
> works or whether it'd be possible.
>
>   - The way zope.testing promotes writing layers is actually pretty
> evil. It overloads the 'class' keyword, essentially, making you spell
> "base layers" as base classes. This has a few problems:

>
>     - If your "base layer" has a testTearDown method, say, and your
> layer doesn't, the base class version will actually inherit into the
> child layer. zope.testing will then run the same code twice, once for
> the base layer and once for the child layer.
>
>     - You can't use OOP inheritance to re-use layer conveniences.
>
>     - People get quite confused. :)
>
>     - You can't have two copies of a layer - all layers are
> module-level global singletons. This becomes somewhat important when
> layers manage and expose resources (like database connections).

Minor note: zope.testing *promotes* layers the wrong way and 
zope.app.testing definitely implements them the wrong way.

However, the testrunner itself deals with them in a way that allows you 
to use them correctly. I think the situation itself could be remedied if 
the actual layers that are around would be rewritten and a few 
annoyances (handling of missing methods) straightened out.


-- 
Christian Theune · [email protected]
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )