Merge lp:~free.ekanayaka/python-zope-fixtures/adapter-fixture into lp:python-zope-fixtures
Status: | Merged |
---|---|
Merged at revision: | 8 |
Proposed branch: | lp:~free.ekanayaka/python-zope-fixtures/adapter-fixture |
Merge into: | lp:python-zope-fixtures |
Diff against target: |
239 lines (+151/-13) 3 files modified
lib/zope_fixtures/__init__.py (+3/-1) lib/zope_fixtures/components.py (+77/-9) lib/zope_fixtures/tests/test_components.py (+71/-3) |
To merge this branch: | bzr merge lp:~free.ekanayaka/python-zope-fixtures/adapter-fixture |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins | Approve | ||
Review via email: mp+124187@code.launchpad.net |
Description of the change
I realized that the ComponentsFixture might not be a good idea, or at least it probably doesn't match the typical use cases one would have in a Zope-based application.
The reason is that it uses the low-level sethook() API to override the current registry (aka site manager), while Zope actually supports an higher-level API in the zope.components
I believe ComponentsFixture should be dropped and maybe replaced with a SiteFixture which would use the setHooks/setSite APIs to offer a similar behavior, but more in line with what the Zope publisher does, and hence more suited for writing unit-tests.
Said that, this branch heads into that direction and re-implements UtilityFixture without using ComponentsFixture under the hood, and merely using whatever site manager is currently in-force (thus letting test code be in control of the site manager). It also adds an AdapterFixture which pretty much does the same, but with adapters.
It should be possible to virtually get the same features of ComponentsFixture using UtilityFixture and AdapterFixture.
FWIW more information on the canonical use of hooks in a Zope application can be found in zope/component/ hooks.txt and zope/site/site.txt.