[Zope3-dev] zope.configuration

Jim Fulton jim at zope.com
Fri Mar 17 10:46:54 EST 2006


Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>> Martijn Faassen wrote:
>>
>>> Jim Fulton wrote:
> 
> [snip]
> 
>> The idea is that after applying configuration, you'd keep the
>> resolved sequence of actions around so that you could call their undo
>> methods later.
> 
> 
> Yes, that's what I was thinking of too. Good. :)

I'll note that this is a half baked idea and may not work.
In particular, as successful "undo" would need to restore
configuration that the action overrode.  I'm not sure that
the benefit is worth the bother of getting this right.



> 
> [snip]
> 
>>> I was talking to Philipp last night about providing an equivalent API 
>>> that looks exactly like ZCML but is in Python. The motivation was 
>>> that this would help in making testing easier - if you want to 
>>> accomplish the equivalent effect of ZCML, you would write Python code 
>>> that's the same. My idea however was that it would execute the 
>>> actions immediately, which is different from actually generating 
>>> actions as you suggest here.
>>
>>
>> I'll note that we typically write 3 kinds of tests:
>>
>> 1, Unit tests.  For these we go out of our way to avoid
>>    configuration.  We make agressive use of skaffolding, if
>>    necessary, to avoid dependence on other systems.
>>
>> 2, Component functional tests.  These are tests of a package
>>    using the default configuration use by the package.  This
>>    allows us to test things like configuration and UI without
>>    depending on a particular application.  This was the primary
>>    motivation for layers in the new test runner.
>>
>> 3. System tests, in which we test a very specific configured
>>    application.
>>
>> For 1, we don't need configuration support.  For 2 and 3 it's
>> important to use exactly the ZCML provided by the package or
>> by the application respectively.  Fly what you test, and test what
>> you fly.  If you use ZCML for configurating, use it for functional
>> and system tests.
> 
> 
> Agreed. However...
> 
> For 1. we don't need configuration support, but what I think could be 
> improved is the skaffolding. Often in unit tests we do register 
> something with the component architecture.

This can be avoided more often than you realize.  Also, there
are simple APIs that make this straightforward when it is necessary.


> Right now we need to know two 
> systems whenever we write code that needs unit tests:
> 
> * ZCML for when the code needs to actually run
> 
> * component architecture APIs when we need to set up some stuff to 
> support our tests.
> 
> What I'm suggesting is having a Python API that looks much like ZCML but 
> does the component architecture registration bit of what ZCML does. Less 
> things to learn for the person writing (or reading) the scaffolding for 
> the tests.

OK,  I think we'll be better served by different APIs. An API necessary
to create actions will, I think, be too combersome for simple registration
needed by tests.


> Since we also were talking about a Python API to generate ZCML actions, 
> it seems to make sense that the same API could also have an 
> implementation that *does* generate actions.

ZCML actions require information that isn't necessary when just registering
components for tests.

I won't argue.  If we create an API for configuration, and you want to
use it for setting up tests, be my guest.  I'll stick to the simpler APIs
myself.

I'll note, however, that I think there will be lots of interesting
small Python applications that don't use zope.configuration.
zope.configuration is helpful for providing flexible configuration
of an application server. I think and hope that there will be lots
of interesting applications that don't use an application server
and that do use Zope components.  These components should not depend
on zope.configuration and their unit tests should not introduce such
a dependency or be made more complex just to provide some sort of
consistency.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org



More information about the Zope3-dev mailing list