diff options
| author |   Cedric Ollivier <cedric.ollivier@orange.com> | 2017-05-30 15:02:06 +0000 |
|---|---|---|
| committer |   Gerrit Code Review <gerrit@opnfv.org> | 2017-05-30 15:02:06 +0000 |
| commit | a28e2b40877f022f6cc8bbc3ad9b586ef3dd126c (patch) | |
| tree | 015109b1867976702a2e90b050d00af0174f2b73 /docs/testing/user | |
| parent | 8628e8f2bb97f4528767710ec8fdec5ea3643738 (diff) | |
| parent | 49a7e57f112d855b0609721b6082b15a94417380 (diff) | |
Merge "Define create_snapshot() and clean() in TestCase"
Diffstat (limited to 'docs/testing/user')
| -rw-r--r-- | docs/testing/user/userguide/runfunctest.rst | 10 |
1 files changed, 2 insertions, 8 deletions
diff --git a/docs/testing/user/userguide/runfunctest.rst b/docs/testing/user/userguide/runfunctest.rst index 07b5b8a6..c155e609 100644 --- a/docs/testing/user/userguide/runfunctest.rst +++ b/docs/testing/user/userguide/runfunctest.rst @@ -561,14 +561,9 @@ the Functest environment (i.e. CLI command 'functest env prepare') to snapshot all the OpenStack resources (images, networks, volumes, security groups, tenants, users) so that an eventual cleanup does not remove any of these defaults. -It is also called before running a test except if it is disabled by configuration -in the testcases.yaml file (clean_flag=false). This flag has been added as some -upstream tests already include their own cleaning mechanism (e.g. Rally). - The script **openstack_clean.py** which is located in -*$REPOS_DIR/functest/functest/utils/* is normally called after a test execution. It is -in charge of cleaning the OpenStack resources that are not specified in the -defaults file generated previously which is stored in +*$REPOS_DIR/functest/functest/utils/* is in charge of cleaning the OpenStack resources +that are not specified in the defaults file generated previously which is stored in */home/opnfv/functest/conf/openstack_snapshot.yaml* in the Functest docker container. It is important to mention that if there are new OpenStack resources created @@ -660,7 +655,6 @@ For a given test case we defined: * the name of the test case * the criteria (experimental): a criteria used to declare the test case as PASS or FAIL * blocking: if set to true, if the test is failed, the execution of the following tests is canceled - * clean_flag: shall the functect internal mechanism be invoked after the test * the description of the test case * the dependencies: a combination of 2 regex on the scenario and the installer name * run: In Danube we introduced the notion of abstract class in order to harmonize the way to run internal, feature or vnf tests |