Open kloczek opened 3 months ago
Just tested 6.0 and I still see those fails.
In mean time to be able test BTrees
with "test as installed" methodology typically used on packaging I made patch which removes all relative imports.
Would you accept as PR below patch?
If the tests do not fail with these changes I'd accept the PR.
If the tests do not fail with these changes I'd accept the PR.
With that patch it is possible at all test your module because without it is not possible to pass scanning units.
Please keep in mind: The tests have to succeed with zope.testrunner
. If your planned changes help for pytest
compatiblity I do not mind.
I understand that .. however correctly written zope test runner test suite should be correctly handled by pytest which by the way is much more flexible and reach of possible to use features. I'm only flagging some issues in such scenario.
Tomasz Kłoczko wrote at 2024-6-5 02:21 -0700:
I understand that .. however correctly written zope test runner test suite should be correctly handled by pytest which by the way is much more flexible and reach of possible to use features.
We already had a discussion like this.
When I remember right, you have not yet answered a question in this context:
does pytest
support "layer"s?
A test can be associated with a "layer".
A "layer" is a class with optional setUp
and tearDown
methods.
zope.testrunner
executes all tests associated with the same layer
in a shared set up built by the "layer"s setUp
before the first such
test, shared by all those tests and torn down after all those tests
by the "layer"s tearDown
).
"layer"s are organized via the class inheritance, i.e. "layer"s can
be nested.
The zopefoundation
projects typically make significant use
of the "layer" concept in order to reduce the test time.
If a test runner does not support it, failures are to be expected.
pytest
does not support layers. There is zope.pytestlayer
which – as a plug-in – adds layer support; but it has its own problems. There are currently more important maintainance tasks on my list. The test runner is one of the least problems I currently have.
I'm packaging your module as an rpm package so I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.
python3 -sBm build -w --no-isolation
build
with--no-isolation
I'm using during all processes only locally installed modulesinstaller
modulecut off from access to the public network
(pytest is executed with-m "not network"
)List of installed modules in build env:
```console Package Version ----------------------------- ----------- alabaster 0.7.16 Babel 2.15.0 build 1.2.1 cffi 1.16.0 charset-normalizer 3.3.2 defusedxml 0.7.1 docutils 0.20.1 exceptiongroup 1.1.3 idna 3.7 imagesize 1.4.1 importlib_metadata 7.1.0 iniconfig 2.0.0 installer 0.7.0 Jinja2 3.1.4 jupyterlab_pygments 0.3.0 MarkupSafe 2.1.5 packaging 24.0 persistent 5.2 pluggy 1.5.0 ply 3.11 pycparser 2.22 Pygments 2.18.0 pyproject_hooks 1.0.0 pytest 8.2.1 python-dateutil 2.9.0.post0 repoze.lru 0.7 repoze.sphinx.autointerface 1.0.0 requests 2.32.2 setuptools 69.4.0 snowballstemmer 2.2.0 Sphinx 7.3.7 sphinxcontrib-applehelp 1.0.8 sphinxcontrib-devhelp 1.0.6 sphinxcontrib-htmlhelp 2.0.5 sphinxcontrib-jsmath 1.0.1 sphinxcontrib-qthelp 1.0.7 sphinxcontrib-serializinghtml 1.1.10 tokenize_rt 5.2.0 tomli 2.0.1 transaction 4.0 urllib3 2.2.1 wheel 0.43.0 zipp 3.18.2 zope.event 5.0 zope.interface 6.4.post2 ```Please let me know if you need more details or want me to perform some diagnostics.