summaryrefslogtreecommitdiffstats
path: root/docs/testing/user
diff options
context:
space:
mode:
authorCedric Ollivier <cedric.ollivier@orange.com>2017-05-30 15:02:06 +0000
committerGerrit Code Review <gerrit@opnfv.org>2017-05-30 15:02:06 +0000
commita28e2b40877f022f6cc8bbc3ad9b586ef3dd126c (patch)
tree015109b1867976702a2e90b050d00af0174f2b73 /docs/testing/user
parent8628e8f2bb97f4528767710ec8fdec5ea3643738 (diff)
parent49a7e57f112d855b0609721b6082b15a94417380 (diff)
Merge "Define create_snapshot() and clean() in TestCase"
Diffstat (limited to 'docs/testing/user')
-rw-r--r--docs/testing/user/userguide/runfunctest.rst10
1 files changed, 2 insertions, 8 deletions
diff --git a/docs/testing/user/userguide/runfunctest.rst b/docs/testing/user/userguide/runfunctest.rst
index 07b5b8a60..c155e6090 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