Allow a class method decorated `@staticmethod` to be collected as a test
function (if it meets the usual criteria).
This feature will not work in Python 2.6 -- static methods will still be
ignored there.
This works by adding an argparse Action that will raise an exception in
order to skip the rest of the argument parsing. This prevents argparse
from quitting due to missing required arguments, similar to the way that
the builtin argparse --help option is implemented by raising SystemExit.
Fixes: #1999
Descriptors (e.g. properties) such as in the added test case are
triggered during collection, executing arbitrary code which can raise.
Previously, such exceptions were propagated and failed the collection.
Now these exceptions are caught and the corresponding attributes are
silently ignored.
A better solution would be to completely skip access to all custom
descriptors, such that the offending code doesn't even trigger. However
I think this requires manually going through the instance and all of its
MRO for each and every attribute checking if it might be a proper
fixture before accessing it. So I took the easy route here.
In other words, putting something like this in your test class is still
a bad idea...:
@property
def innocent(self):
os.system('rm -rf /')
Fixes#2234.
Currently if the terminal report of testdir.runpytest() is missing,
assert_outcomes() on its output fails because parseoutcomes()
returns an unexpected value (None).
It's better to fail parseoutcomes() directly.
Fix#1649
Users of unittest style TestCases will create expensive objects
in setUp. We should clean up TestCase instances that are lying
around so that they don't fill up memory.
Until now, teardown stdout/stderr output was not reported upon test failure.
However such output is sometime necessary to understand the failure.
fix#442
Merge branch 'pkg_resources_bugfix' of github.com:raquel-ucl/pytest into pkg-resources
This is an odd case and doesn't really make sense, it is working around a bug
in maven/jython and the old version or weird packaging of setuptools they use.
But we used to do this in the past so might as well keep doing this.
Test case for overriding autouse fixture with a parametrized fixture.
The test covers the problem explained in the issue 1601
Adding Diego Russo to AUTHORS
Add --continue-on-collection-errors option to restore the previous behaviour:
Execute tests (that were successfully collected) even when collection errors
happen.
Some tests had to be modified e.g. because the return code changed to 2
(EXIT_INTERRUPTED) instead of 1 (EXIT_TESTSFAILED) because an Interrupted
exception is raised on collection error.
Implemented via pair programming with:
Oleg Pidsadnyi <oleg.pidsadnyi@gmail.com>
closes#1421
The inner function and the explanatory comment it makes necessary can
all be removed if we switch to an if/else rather than try/except for
this condition.
Perhaps this bit comes from my fondness for C, but I think I would
find this style clearer and easier to understand even if it weren't
for the Python 2 quirk that makes the other style require us to add an
unnecessary-looking function abstraction. In any case, given that the
alternative does require that abstraction this is definitely simpler.
When the method argument is missing on teardown_method, the traceback is
100% internal to pytest, which with default options get pruned. Then
that traceback is empty, leading to a new exception as a traceback shall
not be empty.
This PR fixes that issue by pushing back the last stack on the
traceback, when the stacktrace is empty after pruning. Then the output
is still pruned, but gives meaningful information with the item where it
failed on the stack.
* fixes issue #1604
Signed-off-by: Guyzmo <guyzmo+github@m0g.net>
__test__ needs to be checked for methods of a class too. Earlier,
this was not done, and all methods in a class was assumed to be
a test. This commit adds the appropriate condition to ensure that
if the __test__ is set to False, it does not collect that method.
Fixes https://github.com/pytest-dev/pytest/issues/1558
The commit allow users to add a properties node in testsuite level see
example below:
<testsuite errors="0" failures="0" name="pytest" skips="1" tests="1"
time="11.824">
<properties>
<property name="ARCH" value="PPC"/>
<property name="OS" value="RHEL 7.2"/>
<property name="TestPlanURL" value="https://url.."/>
<property name="Automated" value="True"/>
</properties>
<testcase classname="git.....>
</testcase>
</testsuite>
The current situation is that properties node can be added to every
testcase node. However, sometimes we need some global properties that
applies to all testcases and give better description for the testsuite
itself.
When defining a fixture in the same module as where it is used, the
function argument shadows the fixture name, which a) annoys pylint and
b) can lead to bugs where you forget to request a fixture into a test
method.
This allows one to define fixtures with a different name than the name
of the function, bypassing that problem.
a more descriptive docstring (the workaround itself is just to import
readline earlier). I removed the conditional on targetfd from the
workaround since it doesn't really matter.
* Added # noqa marker.
* Added changelog entry, and self to authors.
Fixes issue 331
previously to this change the collection code would issue a warning for
when ever it encountered a variable that looked like a test but wasn't a
function saying that it wouldn't collect it because it wasn't a function.
This fixes the logic so that if that warning is issued it really isn't
collected.
However previously special cases existed to support tests that were
created using functools.wraps and functools.partial. So the condition for
issuing that warning has been updated to take that in to account
Also try the old way of detecting functions just for proper integration
with mock.path in python 2.7 the get_real_func returned the unbound method