💻 動作環境 💻
⭐️ チャプター ⭐️
This plugin produces coverage reports. Compared to just using
coverage run this plugin does some extras:
coverage run -m pytestyou will have slightly different
sys.path(CWD will be in it, unlike when running
All features offered by the coverage package should work, either through pytest-cov's command line options or through coverage's config file.
Install with pip:
pip install pytest-cov
For distributed testing support install pytest-xdist:
pip install pytest-xdist
pytest-cov 2.0 is using a new
.pth file (
pytest-cov.pth). You may want to manually remove the older
init_cov_core.pth from site-packages as it's not automatically removed.
Uninstall with pip:
pip uninstall pytest-cov
Under certain scenarios a stray
.pth file may be left around in site-packages.
pytest-cov.pthif you installed without wheels (
pytest --cov=myproj tests/
Would produce a report like:
-------------------- coverage: ... --------------------- Name Stmts Miss Cover ---------------------------------------- myproj/__init__ 2 0 100% myproj/myproj 257 13 94% myproj/feature4286 94 7 92% ---------------------------------------- TOTAL 353 20 94%
The data file is erased at the beginning of testing to ensure clean data for each test run. If you need to combine the coverage of several test runs you can use the
--cov-append option to append this coverage data to coverage data from previous test runs.
The data file is left at the end of testing so that it is possible to use normal coverage tools to examine it.
For distributed testing the workers must have the pytest-cov package installed. This is needed since the plugin must be registered through setuptools for pytest to start the plugin on the worker.
For subprocess measurement environment variables must make it from the main process to the subprocess. The python used by the subprocess must have pytest-cov installed. The subprocess must do normal site initialisation so that the environment variables can be detected and coverage started.
Whilst this plugin has been built fresh from the ground up it has been influenced by the work done on pytest-coverage (Ross Lawley, James Mills, Holger Krekel) and nose-cover (Jason Pellerin) which are other coverage plugins.
Ned Batchelder for coverage and its ability to combine the coverage results of parallel runs.
Holger Krekel for pytest with its distributed testing support.
Jason Pellerin for nose.
Michael Foord for unittest2.
No doubt others have contributed to these tools as well.
Source Code: https://github.com/pytest-dev/pytest-cov
License: MIT License
An extension of pytest test runner which provides a set of useful tools to simplify testing and development of the Flask extensions and applications.
To view a more detailed list of extension features and examples go to the PyPI overview page or package documentation.
Considering the minimal flask application factory bellow in
myapp.py as an example:
from flask import Flask def create_app(config_filename): # create a minimal app app = Flask(__name__) app.config.from_pyfile(config_filename) # simple hello world view @app.route('/hello') def hello(): return 'Hello, World!' return app
You first need to define your application fixture in
from myapp import create_app @pytest.fixture def app(): app = create_app() return app
Finally, install the extension with dependencies and run your test suite:
$ pip install pytest-flask $ pytest
Don’t hesitate to create a GitHub issue for any bug or suggestion. For more information check our contribution guidelines.
Source Code: https://github.com/pytest-dev/pytest-flask
License: MIT License
This Edureka video on ‘Pytest’ will help you understand how we can write simple tests in python with a use case for testing an API. Following are the topics discussed:
What is Pytest?
Getting Started With Pytest
Create Your First Test With Pytest
Grouping Multiple Tests
Testing An API Using Pytest
#python #pytest #testing
Mypy static type checker plugin for pytest
You can install "pytest-mypy" via pip from PyPI:
$ pip install pytest-mypy
You can enable pytest-mypy with the
$ py.test --mypy test_*.py
Mypy supports reading configuration settings from a
mypy.ini file. Alternatively, the plugin can be configured in a
conftest.py to invoke mypy with extra options:
def pytest_configure(config): plugin = config.pluginmanager.getplugin('mypy') plugin.mypy_argv.append('--check-untyped-defs')
You can restrict your test run to only perform mypy checks and not any other tests by using the -m option:
py.test --mypy -m mypy test_*.py
Source Code: https://github.com/dbader/pytest-mypy
License: MIT license
pytest-mypy-testing — Plugin to test mypy output with pytest
pytest-mypy-testing provides a pytest plugin to test that mypy produces a given output. As mypy can be told to display the type of an expression this allows us to check mypys type interference.
python -m pip install pytest-mypy-testing
The Python distribution package contains an entry point so that the plugin is automatically discovered by pytest. To disable the plugin when it is installed , you can use the pytest command line option
Writing Mypy Output Test Cases
A mypy test case is a top-level functions decorated with
@pytest.mark.mypy_testing in a file named
*.mypy-testing or in a pytest test module.
pytest-mypy-testing follows the pytest logic in identifying test modules and respects the
python_files config value.
pytest-mypy-testing uses the Python ast module to parse candidate files and does not import any file, i.e., the decorator must be exactly named
In a pytest test module file you may combine both regular pytest test functions and mypy test functions. A single function can be both.
Example: A simple mypy test case could look like this:
@pytest.mark.mypy_testing def mypy_test_invalid_assignment() -> None: foo = "abc" foo = 123 # E: Incompatible types in assignment (expression has type "int", variable has type "str")
The plugin runs mypy for every file containing at least one mypy test case. The mypy output is then compared to special Python comments in the file:
# N: <msg>- we expect a mypy note message
# W: <msg>- we expect a mypy warning message
# E: <msg>- we expect a mypy error message
# R: <msg>- we expect a mypy note message
Revealed type is '<msg>'. This is useful to easily check
Mypy test case functions can be decorated with
@pytest.mark.xfail to mark them as to-be-skipped and as expected-to-fail, respectively. As with the
@pytest.mark.mypy_testing mark, the names must match exactly as the decorators are extracted from the ast.
python -m pip install -U -r requirements.txt.
PYTEST_VERSION_INFO- by @blueyed (#8)
--check-untyped-defsto mypy (#11)
python_fileswhen identifying pytest test modules (#12)
inv tox -e py-*) (#6)
@pytest.mark.mypy_testing def mypy_use_reveal_type(): reveal_type(123) # N: Revealed type is 'Literal?' reveal_type(456) # R: Literal?
Source Code: https://github.com/davidfritzsche/pytest-mypy-testing