Skip to content

Commit 8f36696

Browse files
committed
Update the testing documentation
1 parent 94957ca commit 8f36696

File tree

1 file changed

+29
-18
lines changed

1 file changed

+29
-18
lines changed

source/developers/development_testing.markdown

Lines changed: 29 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -9,31 +9,28 @@ sharing: true
99
footer: true
1010
---
1111

12-
As states in the [Style guidelines section](/developers/development_guidelines/) all code is checked as part of the linting process and unit test were run.
13-
14-
### {% linkable_title Local testing %}
15-
16-
**Important:** Run `tox` before you create your pull request to avoid annoying fixes. Local testing requires installing `tox`.
12+
As states in the [Style guidelines section](/developers/development_guidelines/) all code is checked to verify all unit tests pass and that the code passes the linting tools. Local testing is done using Tox, which has been installed as part of running `script/setup`. To start the tests, simply run it:
1713

1814
```bash
19-
$ pip3 install tox
15+
$ tox
2016
```
17+
**Important:** Run `tox` before you create your pull request to avoid annoying fixes.
2118

22-
Start your code test with `tox`.
19+
Running Tox will run unit tests against the locally available Pythons, as well as validate the code and document style using `pycodestyle`, `pydocstyle` and `pylint`. You can run tests on only one tox target -- just use `-e` to select an environment. For example, `tox -e lint` runs the linters only, and `tox -e py34` runs unit tests only on Python 3.4.
2320

24-
```bash
25-
$ tox
26-
```
21+
Tox uses virtual environments under the hood to create isolated testing environments. The tox virtual environments will get out-of-date when requirements change, causing test errors. Run `tox -r` to tell Tox to recreate the virtual environments.
2722

28-
This will run unit tests against Python 3.4 and 3.5 (if both are available locally), as well as tests that validate `pep8` and `pylint` style.
23+
If you are working on tests for a component or platform and you need the dependencies available inside the Tox environment, update the list inside `script/gen_requirements_all.py`. Then run the script and then run `tox -r` to recreate the virtual environments.
2924

30-
#### {% linkable_title Testing Tips %}
25+
### {% linkable_title Testing single files %}
3126

32-
You can run tests on only one tox target -- just use `-e` to select an environment. For example, `tox -e lint` runs the linters only, and `tox -e py34` runs unit tests only on Python 3.4.
27+
Running tox will invoke the full test suite. Even if you specify which tox target to run, you still run all tests inside that target. That's not very convenient to quickly iterate on your code! To be able to run the specific test suites without Tox, you'll need to install the test dependencies into your Python environment:
3328

34-
tox uses virtual environments under the hood to create isolated testing environments. The tox virtual environments will get out-of-date when requirements change, causing test errors. Run `tox -r` to create new tox virtual environments.
29+
```bash
30+
$ bash pip3 install -r requirements_test_all.txt
31+
```
3532

36-
During development on a specific file, speed up your workflow by running tests and linting only for the file that you're working on. To run individual files:
33+
Now that you have all test dependencies installed, you can run tests on individual files:
3734

3835
```bash
3936
$ flake8 homeassistant/core.py
@@ -48,8 +45,23 @@ You can also run linting tests against all changed files, as reported by `git di
4845
$ script/lint --changed
4946
```
5047

48+
#### {% linkable_title Py.test tips %}
49+
50+
Py.test has some great command line parameters to help you with the write-test-fix cycle.
51+
52+
```bash
53+
# Stop after the first test fails
54+
$ py.test tests/test_core.py -x
55+
# Run test with specified name
56+
$ py.test tests/test_core.py -k test_split_entity_id
57+
# Fail a test after it runs for 2 seconds
58+
$ py.test tests/test_core.py --timeout 2
59+
# Show the 10 slowest tests
60+
$ py.test tests/test_core.py --duration=10
61+
```
62+
5163
### {% linkable_title Preventing Linter Errors %}
52-
64+
5365
Save yourself the hassle of extra commits just to fix style errors by enabling the Flake8 git commit hook. Flake8 will check your code when you try to commit to the repository and block the commit if there are any style errors, which gives you a chance to fix them!
5466

5567
```bash
@@ -61,5 +73,4 @@ The `flake8-docstrings` extension will check docstrings according to [PEP257](ht
6173

6274
### {% linkable_title Notes on PyLint and PEP8 validation %}
6375

64-
If you can't avoid a PyLint warning, add a comment to disable the PyLint check for that line with `# pylint: disable=YOUR-ERROR-NAME`. An example of an unavoidable PyLint warning is not using the passed-in datetime if you're listening for a time change.
65-
76+
If you can't avoid a PyLint warning, add a comment to disable the PyLint check for that line with `# pylint: disable=YOUR-ERROR-NAME`. Example of an unavoidable one is if PyLint incorrectly reports that a certain object doesn't have a certain member.

0 commit comments

Comments
 (0)