GitLocker: The Coding Marketplace

Description:

pytestconfig 0.0.11

pytest-config

Base configurations and utilities for developing your Python project test suite.

Installation
pip install git+git://github.com/buzzfeed/pytest_config.git@<version>#egg=pytest_config==<version>
This will install:

pytest_config py.test plugin
a simple django app that extends the django-admin.py startapp (under development).
a pytest_config.init command to initialize new config files
a pytest_config.update command to interactively update your config files
against the lates default values.

Features

Automatic fix for the sys.path known issue.
pytest_config takes care of the sys.path known issue between pytest and pytest-django
by automatically adding the current working directory to the PYTHONPATH before tests run.

Management of configuration files
$ pytest_config.init [options]
This command will copy all the configuration files needed to easily configure
py.test and coverage. Beware of this command as it will simply replace any
existing config files in you current directory.
$ pytest_config.update [options]
This command will read the default configuration files and your customized
configuration files. If any of the options in you custom configuration differs
from the defaults, you will be prompted if you want to keep the current one.
If you decline, the default will be saved to your local configuration.

Available options
The two previous commands share a few of their interface, which is as follows:

pytest_config.[init|update] -h prints the help page.
pytest_config.[init|update] --coverage makes the command apply its operations
only for the .coveragerc file.
pytest_config.[init|update] --pytest-ini makes the command apply its operations
only for the pytest.ini file.

pytest_config.update has additional options, though:

pytest_config.update -y silences the process so that you are not prompted
about anything. All the defaults will be automatically applied if you use this.

Automatic test marking
pytest_config automatically marks your tests at runtime with markers based on
what directories the tests are in, so under this architecture:
project_root/
app_name/
tests/ # root `tests` directory
├── __init__.py
└── app_name/
├── __init__.py
├── integration/
│ ├── __init__.py
│ └── test_foo.py
└── unit/
├── __init__.py
└── test_bar.py

test functions/methods inside app_name/unit/*.py will be marked with
@pytest.mark.<app_name> and @pytest.mark.unit
test functions/methods inside app_name/integration/*.py will be marked with
@pytest.mark.<app_name> and @pytest.mark.integration

and so on. This will allow you to run tests on a per-app and per-type basis by running:
$ py.test -m unit
$ py.test -m integration
$ py.test -m app_name
$ py.test -m 'app_name and <type>'
$ py.test -m '<type> and app_name'

Integration with Caliendo
The following command line arguments have been added to py.test to integrate it
smoothly with Caliendo:

py.test --caliendo: Enable the overall use of caliendo in your tests.
py.test --caliendo-prefix path/to/caliendo/files: Set the path to where the caliendo
files should live. If you are defining this yourself, it’s recommended that you set it as a path
relative to your current working directory, i.e. caliendo, ./caliendo,
whatever/caliendo and not as an absolute path. Defaults to $PWD/caliendo.
py.test --caliendo --caliendo-purge: Set the CALIENDO_PURGE environment variable so that
caliendo can get rid of unused cache, evs, etc.
py.test --caliendo --caliendo-prompt: Set the CALIENDO_PROMPT environment variable
so that you may use the interactive prompt built in caliendo