Jim Fulton wrote:
Martijn Faassen wrote:

Jim Fulton wrote:

Martijn Faassen wrote:

Jim Fulton wrote:


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.

That's true, I hadn't considered that.

[skaffolding in unit tests]
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.

It's a good thing you know what I realize. :) Anyway, I've seen lots of testing code that does not avoid this. The people who wrote this test might have done it unnecessarily, but that points to doing it the right way apparently being harder than doing it the wrong way. Are you saying this is an education/documentation issue?

Also, there
are simple APIs that make this straightforward when it is necessary.

I know. I'm looking for ways to make it even simpler, as I've seen people actually
run into this issue.

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.

Yes, two APIs, same interface. One creates actions, the other one doesn't. The one creating the actions could hopefully be implemented in terms of the other.

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

Sounds good.

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

That's a good point. Perhaps the API I'm talking about belongs in zope.component (and anything else that ZCML statements exist for, in the end). It's likely a very thin layer over what's already there. Then zope.configuration can take the interfaces and implement an action-based and ZCML based system for them.

Anyway, it's just an idea. Maybe I'll find some time to look into this eventually. I know enough of the innards of zope.configuration by now to also be potentially helpful in trying to pull it apart into a Python API (the action-generating one) and the ZCML bit.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to