...
When a change is 100% covered by existing unit tests, there is no need to specify additional tags.
When a change is covered by new unit tests, you might need to specify the corresponding Feature Tag.
When a change is not 100% covered by unit tests, you do need to specify the corresponding Feature Tag.
E.g. Middleware applications, high-level functional verification, 3rd-party libraries, integration
When a change modifies Functional Tests or the Functional Test Framework, you do need to specify the corresponding Feature Tags and/or Specific Test Tags.
When a change fixes a specific Functional Test, you do need to specify the corresponding Specific Test Tags.
List of Frequency Tags
These tags determine when a test runs. Some tests might be ran at multiple frequencies.
...
Avocado Tag | Description |
---|---|
| Verifies |
| Verifies |
| Verifies |
| Verifies Data Mover utilities. Additional sub-tags:
|
| Verifies |
| Verifies DAOS on a newly deployed system. |
| Verifies |
| Verifies |
| Verifies |
| Verifies |
| Verifies online and offline |
| Verifies features related to |
| Verifies |
| Verifies |
| Verifies |
| Verifies |
Anchor | ||||
---|---|---|---|---|
|
Each test has a unique tag that can be used to run only that test. When there is need to run a specific test, the tag must be looked up in the corresponding ftest/<dir>/<test_file>.py
. Unique test tags are usually on the last line of Avocado tags. For example, from ftest/pool/evict.py, the pool_evict_basic
tag will run only this test:
Code Block | ||
---|---|---|
| ||
def test_evict(self):
"""
:avocado: tags=all,pr,daily_regression
:avocado: tags=vm
:avocado: tags=pool,pool_evict
:avocado: tags=pool_evict_basic
""" |