[Zope3-dev] zope.configuration

[Martijn Faassen]

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. :)

[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. 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.

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.

>>> I'd have no problem with generating actions in Python.  It would allow
>>> greater control and would probably make action generation much faster.
>>> If we did this, We'd probably want to improve the action-generation
>>> API.  We'd also need to think about how action info should be
>>> generated, especially wrt error reporting.
>>>
>>> Perhaps we should support both ZCML and python action generation.
>>
>> I think that this would be a useful direction to go towards, if only 
>> to make writing tests easier (only one API to learn instead of the 
>> underlying APIs that are used by ZCML).
>  
> I strongly oppose and discourage using a separate API for tests, for
> the reasons given above.
> 
> The main reasons, IMO, for providing a Python API are:
> 
> - Provide greater control for those who want it.
>   For example, to allow more abstract configuration tools,
>   avoid "repetition", etc.
> 
> - Provide an alternative for people who just can't stand pointy
>   brackets. (Who can blame them? ;)

Perhaps I'm wrong, but I think you might not have understood my reasons 
for wanting ZCML-similar API for unit tests. I absolutely agree that for 
functional tests, the same configuration should be used as when the code 
actually runs. I wasn't talking about that however - I hope I explained 
more clearly now why this might be a good idea for *unit* tests, where 
effectively a separate API is already being used to set up the various 
components (skaffolding). If we are to present a Python-style API for 
ZCML anyway, reusing it (with a different implementation) seems like 
low-hanging consistency fruit.

Regards,

Martijn