west/tox.ini

42 lines
1.1 KiB
INI
Raw Normal View History

# Benefits of using tox:
#
# 1. makes sure we are testing west as installed by setup.py
# 2. avoid touching user global / system config files
# 3. avoid touching any git repositories outside of tmpdirs
# 4. ensure global / system config settings have no effect on the tests
tests: use tox and overhaul project testing To properly test the project commands, it would be best to have a fresh west bootstrapper package created and installed on PATH, so it could be used to run commands exactly as they'd happen if we package and ship the working tree. To make that easier, add a dependency on tox and use it for testing: https://tox.readthedocs.io/en/latest/ From now on, we'll test west by running 'tox' from the repository root. This has several advantages over running pytest directly: - "Just run tox": there are no longer any differences in test invocation between POSIX OSes and Windows. - tox creates an sdist package of the current tree using our setup.py and installs it into a new virtual environment, then runs tests there. This removes interference from other packages installed on the host (like released bootstrappers that are also installed) - we get to run multiple shell commands in order, should that ever be needed, in our test procedures in a way that won't affect users With that done, we can re-work the multirepo command testing to invoke the bootstrapper in the virtual environment, adding various tests and filling in longstanding testing gaps by adding increased checking of the results (currently, much of the testing just checks whether commands do or do not error out, which isn't enough). These changes were made with a view towards the upcoming changes which are planned before releasing west "into the wild": the test case code should be mostly the same before and after the changes, so this serves as a good baseline against regressions introduced by those upcoming changes. Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] debugging shippable results Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] just test one py3 shutil.which west is picking up a 3.4 version in the 3.6 test, oddly Signed-off-by: Marti Bolivar <marti@foundries.io>
2019-01-05 05:41:24 +08:00
[tox]
envlist=py3
tests: use tox and overhaul project testing To properly test the project commands, it would be best to have a fresh west bootstrapper package created and installed on PATH, so it could be used to run commands exactly as they'd happen if we package and ship the working tree. To make that easier, add a dependency on tox and use it for testing: https://tox.readthedocs.io/en/latest/ From now on, we'll test west by running 'tox' from the repository root. This has several advantages over running pytest directly: - "Just run tox": there are no longer any differences in test invocation between POSIX OSes and Windows. - tox creates an sdist package of the current tree using our setup.py and installs it into a new virtual environment, then runs tests there. This removes interference from other packages installed on the host (like released bootstrappers that are also installed) - we get to run multiple shell commands in order, should that ever be needed, in our test procedures in a way that won't affect users With that done, we can re-work the multirepo command testing to invoke the bootstrapper in the virtual environment, adding various tests and filling in longstanding testing gaps by adding increased checking of the results (currently, much of the testing just checks whether commands do or do not error out, which isn't enough). These changes were made with a view towards the upcoming changes which are planned before releasing west "into the wild": the test case code should be mostly the same before and after the changes, so this serves as a good baseline against regressions introduced by those upcoming changes. Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] debugging shippable results Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] just test one py3 shutil.which west is picking up a 3.4 version in the 3.6 test, oddly Signed-off-by: Marti Bolivar <marti@foundries.io>
2019-01-05 05:41:24 +08:00
[flake8]
# We explicitly disable the following errors:
#
# - E126: continuation line over-indented for hanging indent
# - E261: at least two spaces before inline comment
# - E302: expected 2 blank lines, found 1
# - E305: expected 2 blank lines after class or function definition, found 1
# - W504: line break after binary operator
ignore = E126,E261,E302,E305,W504
# Don't lint setup.py, the .tox virtualenv directory, or the build directory
exclude = setup.py,.tox,build
max-line-length = 100
[mypy]
mypy_path=src
ignore_missing_imports=True
tests: use tox and overhaul project testing To properly test the project commands, it would be best to have a fresh west bootstrapper package created and installed on PATH, so it could be used to run commands exactly as they'd happen if we package and ship the working tree. To make that easier, add a dependency on tox and use it for testing: https://tox.readthedocs.io/en/latest/ From now on, we'll test west by running 'tox' from the repository root. This has several advantages over running pytest directly: - "Just run tox": there are no longer any differences in test invocation between POSIX OSes and Windows. - tox creates an sdist package of the current tree using our setup.py and installs it into a new virtual environment, then runs tests there. This removes interference from other packages installed on the host (like released bootstrappers that are also installed) - we get to run multiple shell commands in order, should that ever be needed, in our test procedures in a way that won't affect users With that done, we can re-work the multirepo command testing to invoke the bootstrapper in the virtual environment, adding various tests and filling in longstanding testing gaps by adding increased checking of the results (currently, much of the testing just checks whether commands do or do not error out, which isn't enough). These changes were made with a view towards the upcoming changes which are planned before releasing west "into the wild": the test case code should be mostly the same before and after the changes, so this serves as a good baseline against regressions introduced by those upcoming changes. Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] debugging shippable results Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] just test one py3 shutil.which west is picking up a 3.4 version in the 3.6 test, oddly Signed-off-by: Marti Bolivar <marti@foundries.io>
2019-01-05 05:41:24 +08:00
[testenv]
deps =
setuptools-scm
pytest
pytest-cov
types-PyYAML
flake8
mypy
setenv =
TOXTEMPDIR={envtmpdir}
tests: use tox and overhaul project testing To properly test the project commands, it would be best to have a fresh west bootstrapper package created and installed on PATH, so it could be used to run commands exactly as they'd happen if we package and ship the working tree. To make that easier, add a dependency on tox and use it for testing: https://tox.readthedocs.io/en/latest/ From now on, we'll test west by running 'tox' from the repository root. This has several advantages over running pytest directly: - "Just run tox": there are no longer any differences in test invocation between POSIX OSes and Windows. - tox creates an sdist package of the current tree using our setup.py and installs it into a new virtual environment, then runs tests there. This removes interference from other packages installed on the host (like released bootstrappers that are also installed) - we get to run multiple shell commands in order, should that ever be needed, in our test procedures in a way that won't affect users With that done, we can re-work the multirepo command testing to invoke the bootstrapper in the virtual environment, adding various tests and filling in longstanding testing gaps by adding increased checking of the results (currently, much of the testing just checks whether commands do or do not error out, which isn't enough). These changes were made with a view towards the upcoming changes which are planned before releasing west "into the wild": the test case code should be mostly the same before and after the changes, so this serves as a good baseline against regressions introduced by those upcoming changes. Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] debugging shippable results Signed-off-by: Marti Bolivar <marti@foundries.io> [wip] just test one py3 shutil.which west is picking up a 3.4 version in the 3.6 test, oddly Signed-off-by: Marti Bolivar <marti@foundries.io>
2019-01-05 05:41:24 +08:00
commands =
python -m pytest --cov=west {posargs:tests}
python -m flake8 --config={toxinidir}/tox.ini {toxinidir}
python -m mypy --config-file={toxinidir}/tox.ini --package=west