pax_global_header 0000666 0000000 0000000 00000000064 13710041404 0014504 g ustar 00root root 0000000 0000000 52 comment=4be812e0237572afa23c37c259c414be79557e54
azure-python-devtools-1.2.0/ 0000775 0000000 0000000 00000000000 13710041404 0016006 5 ustar 00root root 0000000 0000000 azure-python-devtools-1.2.0/.coveragerc 0000664 0000000 0000000 00000000145 13710041404 0020127 0 ustar 00root root 0000000 0000000 [run]
branch = True
include = src/*
omit =
*/tests/*
env/*
[paths]
source = src/
[report]
azure-python-devtools-1.2.0/.gitignore 0000664 0000000 0000000 00000002240 13710041404 0017774 0 ustar 00root root 0000000 0000000 # Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# C extensions
*.so
# Distribution / packaging
.Python
env/
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*,cover
.hypothesis/
# Translations
*.mo
*.pot
# Django stuff:
*.log
local_settings.py
# Flask stuff:
instance/
.webassets-cache
# Scrapy stuff:
.scrapy
# Sphinx documentation
docs/_build/
# PyBuilder
target/
# IPython Notebook
.ipynb_checkpoints
# pyenv
.python-version
# celery beat schedule file
celerybeat-schedule
# dotenv
.env
# virtualenv
venv/
ENV/
# Spyder project settings
.spyderproject
# Rope project settings
.ropeproject
# Editor caches
.vscode
.vs
*.pyproj
*.pyproj.user
*.sln
# PyCharm / IntelliJ IDEA
.idea/
# PyTest and its code coverage
.pytest_cache/
azure-python-devtools-1.2.0/.travis.yml 0000664 0000000 0000000 00000000714 13710041404 0020121 0 ustar 00root root 0000000 0000000 sudo: false
language: python
python:
- "2.7"
- "3.5"
- "3.6"
- "3.7"
- "3.8"
install:
- pip install -r requirements.txt
script:
- pylint src/azure_devtools/scenario_tests
- pytest --cov=azure_devtools src/azure_devtools/scenario_tests
after_success:
- codecov
deploy:
provider: pypi
user: Laurent.Mazuel
skip_upload_docs: true
# password: use $PYPI_PASSWORD
distributions: "sdist bdist_wheel"
on:
tags: true
python: '3.6'
azure-python-devtools-1.2.0/LICENSE 0000664 0000000 0000000 00000002237 13710041404 0017017 0 ustar 00root root 0000000 0000000 MIT License
Copyright (c) Microsoft Corporation. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE
azure-python-devtools-1.2.0/Pipfile 0000664 0000000 0000000 00000000354 13710041404 0017323 0 ustar 00root root 0000000 0000000 [[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"
[packages]
"e1839a8" = {path = ".", extras = ["ci_tools"], editable = true}
[dev-packages]
pytest = "*"
codecov = "*"
mock = "*"
pylint = "*"
pytest-cov = "*"
azure-python-devtools-1.2.0/README.rst 0000664 0000000 0000000 00000001772 13710041404 0017504 0 ustar 00root root 0000000 0000000 .. image:: https://travis-ci.org/Azure/azure-python-devtools.svg?branch=master
:target: https://travis-ci.org/Azure/azure-python-devtools
Development tools for Python-based Azure tools
==============================================
This package contains tools to aid in developing Python-based Azure code.
This includes the following components:
scenario_tests
--------------
A testing framework to handle much of the busywork
associated with testing code that interacts with Azure.
ci_tools
--------
Some tooling to help developing CI tools. This includes some Git helpers,
Github RestAPI wrapper and a Bot framework for Github issues.
Contributing
============
This project has adopted the
`Microsoft Open Source Code of Conduct `__.
For more information see the
`Code of Conduct FAQ `__
or contact
`opencode@microsoft.com `__
with any additional questions or comments.
azure-python-devtools-1.2.0/doc/ 0000775 0000000 0000000 00000000000 13710041404 0016553 5 ustar 00root root 0000000 0000000 azure-python-devtools-1.2.0/doc/scenario_base_tests.md 0000664 0000000 0000000 00000011133 13710041404 0023113 0 ustar 00root root 0000000 0000000 # How to write ReplayableTest based VCR tests
The `scenario_tests` package uses the [VCR.py](https://pypi.python.org/pypi/vcrpy) library
to record the HTTP messages exchanged during a program run
and play them back at a later time,
making it useful for creating "scenario tests"
that interact with Azure (or other) services.
These tests can be replayed at a later time without any network activity,
allowing us to detect changes in the Python layers
between the code being tested and the underlying REST API.
## Overview
Tests all derive from the `ReplayableTest` class
found in `azure_devtools.scenario_tests.base`.
This class exposes the VCR tests using the standard Python `unittest` framework
and allows the tests to be discovered by and debugged in Visual Studio.
When you run a test,
the test driver will automatically detect the test is unrecorded
and record the HTTP requests and responses in a .yaml file
(referred to by VCR.py as a "cassette").
If the test succeeds, the cassette will be preserved
and future playthroughs of the test will come from the cassette
rather than using actual network communication.
If the tests are run on TravisCI,
any tests which cannot be replayed will automatically fail.
`ReplayableTest` itself derives from `IntegrationTestBase`,
which provides some helpful methods for use in more general unit tests
but no functionality pertaining to network communication.
## Configuring ReplayableTest
The only configuration of `ReplayableTest` that is "exposed"
(in the sense of being accessible other than through subclassing)
is whether tests should be run in "live" or "playback" mode.
This can be set in the following two ways,
of which the first takes precedence:
* Set the environment variable `AZURE_TEST_RUN_LIVE`.
Any value will cause the tests to run in live mode;
if the variable is unset the default of playback mode will be used.
* Specify a boolean value for `live-mode` in a configuration file,
the path to which must be specified by a `ReplayableTest` subclass as described below
(i.e. by default no config file will be read).
True values mean "live" mode; false ones mean "playback."
"Live" and "playback" mode are actually just shorthand for recording modes
in the underlying VCR.py package;
they correspond to "all" and "once"
as described in the [VCR.py documentation](http://vcrpy.readthedocs.io/en/latest/usage.html#record-modes).
### Subclassing ReplayableTest and features
Most customization of `ReplayableTest` is accessible only through subclassing.
The two main users of `ReplayableTest` are
[azure-cli](https://github.com/Azure/azure-cli)
and [azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python).
Each uses a subclass of `ReplayableTest` to add context-specific functionality
and preserve backward compatibility with test code
prior to the existence of `azure-devtools`.
For example, azure-cli's [compatibility layer](https://github.com/Azure/azure-cli/tree/master/src/azure-cli-testsdk)
adds methods for running CLI commands and evaluating their output.
Subclasses of `ReplayableTest` can configure its behavior
by passing the following keyword arguments when they call
its `__init__` method (probably using `super`):
* `config_file`: Path to a configuration file.
It should be in the format described in Python's
[ConfigParser](https://docs.python.org/3/library/configparser.html) docs
and currently allows only the boolean option `live-mode`.
* `recording_dir` and `recording_name`:
Directory path and file name, respectively,
for the recording that should be used for a given test case.
By default, the directory will be a `recordings` directory
in the same location as the file containing the test case,
and the file name will be the same as the test method name.
A `.yaml` extension will be appended to whatever is used for `recording_name`.
* `recording_processors` and `replay_processors`:
Lists of `RecordingProcessor` instances for making changes to requests and responses
during test recording and test playback, respectively.
See [recording_processors.py](src/azure_devtools/scenario_tests/recording_processors.py)
for some examples and how to implement them.
* `recording_patches` and `replay_patches`:
Lists of patches to apply to functions, methods, etc.
during test recording and playback, respectively.
See [patches.py](src/azure_devtools/scenario_tests/patches.py)
for some examples. Note the `mock_in_unit_test` function
which abstracts out some boilerplate for applying a patch.