171 lines
5.8 KiB
Plaintext
171 lines
5.8 KiB
Plaintext
|
|
introduce py.test.mark.nocollect
|
|
-------------------------------------------------------
|
|
tags: feature 1.2
|
|
|
|
for not considering a function for test collection at all.
|
|
maybe also introduce a py.test.mark.test to explicitely
|
|
mark a function to become a tested one. Lookup JUnit
|
|
ways of tagging tests.
|
|
|
|
introduce py.test.mark registration
|
|
-----------------------------------------
|
|
tags: feature 1.3
|
|
|
|
introduce a hook that allows to register a named mark decorator
|
|
with documentation and add "py.test --marks" to get
|
|
a list of available marks. Deprecate "dynamic" mark
|
|
definitions.
|
|
|
|
do early-teardown of test modules
|
|
-----------------------------------------
|
|
tags: feature 1.3
|
|
|
|
currently teardowns are called when the next tests is setup
|
|
except for the function/method level where interally
|
|
"teardown_exact" tears down immediately. Generalize
|
|
this to perform the "neccessary" teardown compared to
|
|
the "next" test item during teardown - this should
|
|
get rid of some irritations because otherwise e.g.
|
|
prints of teardown-code appear in the setup of the next test.
|
|
|
|
do recursive walk of conftest.py files?
|
|
-----------------------------------------
|
|
tags: feature 1.3
|
|
|
|
it maybe makes sense to generally do a recursive search of conftest.py
|
|
files before command line parsing - this would help to offer the
|
|
full list of options as applicable to a given test project.
|
|
|
|
consider introducing py.test.mark.skip_[not]win32/jython/pyXY
|
|
-------------------------------------------------------------
|
|
tags: feature 1.3
|
|
|
|
conveniently introduce markers for platforms to
|
|
have a shorter form for skipping.
|
|
|
|
generalize parametrized testing to generate combinations
|
|
-------------------------------------------------------------
|
|
tags: feature 1.3
|
|
|
|
think about extending metafunc.addcall or add a new method to allow to
|
|
generate tests with combinations of all generated versions - what to do
|
|
about "id" and "param" in such combinations though?
|
|
|
|
introduce py.test.mark.multi
|
|
-----------------------------------------
|
|
tags: feature 1.3
|
|
|
|
introduce py.test.mark.multi to specify a number
|
|
of values for a given function argument.
|
|
|
|
introduce py.test.mark.multi
|
|
-----------------------------------------
|
|
tags: feature 1.3
|
|
|
|
introduce py.test.mark.multi to specify a number
|
|
of values for a given function argument.
|
|
|
|
have imported module mismatch honour relative paths
|
|
--------------------------------------------------------
|
|
tags: bug 1.2
|
|
|
|
With 1.1.1 py.test fails at least on windows if an import
|
|
is relative and compared against an absolute conftest.py
|
|
path. Normalize.
|
|
|
|
make node._checkcollectable more robust
|
|
-------------------------------------------------
|
|
tags: bug 1.2
|
|
|
|
currently node._checkcollectable() can raise
|
|
exceptions for all kinds of reasons ('conftest.py' loading
|
|
problems, missing rsync-dirs, platform-skip-at-import-level
|
|
issues, ...). It should just return True/False and cause
|
|
a good error message.
|
|
|
|
call termination with small timeout
|
|
-------------------------------------------------
|
|
tags: feature 1.2
|
|
test: testing/pytest/dist/test_dsession.py - test_terminate_on_hanging_node
|
|
|
|
Call gateway group termination with a small timeout if available.
|
|
Should make dist-testing less likely to leave lost processes.
|
|
|
|
have --report=xfailed[-detail] report the actual tracebacks
|
|
------------------------------------------------------------------
|
|
tags: feature
|
|
|
|
there is no way to induce py.test to display the full tracebacks
|
|
of the expected failure. Introduce one.
|
|
|
|
consider globals: py.test.ensuretemp and config
|
|
--------------------------------------------------------------
|
|
tags: experimental-wish 1.2
|
|
|
|
consider deprecating py.test.ensuretemp and py.test.config
|
|
to further reduce py.test globality. Also consider
|
|
having py.test.config and ensuretemp coming from
|
|
a plugin rather than being there from the start.
|
|
|
|
consider allowing funcargs to setup methods
|
|
--------------------------------------------------------------
|
|
tags: experimental-wish 1.2
|
|
|
|
Users have expressed the wish to have funcargs available to setup
|
|
functions. Experiment with allowing funcargs there - it might
|
|
also help to make the py.test.ensuretemp and config deprecation.
|
|
|
|
consider pytest_addsyspath hook
|
|
-----------------------------------------
|
|
tags: 1.2
|
|
|
|
py.test could call a new pytest_addsyspath() in order to systematically
|
|
allow manipulation of sys.path and to inhibit it via --no-addsyspath
|
|
in order to more easily run against installed packages.
|
|
|
|
Alternatively it could also be done via the config object
|
|
and pytest_configure.
|
|
|
|
relax requirement to have tests/testing contain an __init__
|
|
----------------------------------------------------------------
|
|
tags: feature 1.2
|
|
bb: http://bitbucket.org/hpk42/py-trunk/issue/64
|
|
|
|
A local test run of a "tests" directory may work
|
|
but a remote one fail because the tests directory
|
|
does not contain an "__init__.py". Either give
|
|
an error or make it work without the __init__.py
|
|
|
|
|
|
show plugin information in test header
|
|
----------------------------------------------------------------
|
|
tags: feature 1.2
|
|
|
|
Now that external plugins are becoming more numerous
|
|
it would be useful to have external plugins along with
|
|
their versions displayed as a header line.
|
|
|
|
generate/deal with plugin docs
|
|
----------------------------------------------------------------
|
|
tags: feature 1.2
|
|
|
|
review and prepare docs for 1.2.0 release. Probably
|
|
have docs living with the plugin and require them to
|
|
be available on doc generation time, at least when
|
|
the target is the website? Or rather go for interactive help?
|
|
|
|
improved reporting on funcarg usage / name mismatches
|
|
----------------------------------------------------------------
|
|
tags: feature 1.2
|
|
|
|
see to improve help and support for funcarg usage,
|
|
i.e. when a funcarg does not match any provided one.
|
|
Also consider implementing py.test --funcargs to
|
|
show available funcargs - it should honour the
|
|
path::TestClass syntax so one can easily inspect
|
|
where funcargs come from or which are available.
|
|
|
|
|
|
|