Page Comparison

You will need to select appropriate workflow for test executions. There are many workflows available out of box for supported test tools, but you can define your own test tool and workflow as well. Depending on workflow you select, you may have a few inputs to configure.

• Inputs are provided as Groovy expression where you can use various property keys. Here you can use all the available properties (plugin or workflow).
• Note that endpoint execution related (various directory like FD_TEMP_DIR, FD_ARTIFACTS_DIR) variables can not be used here.
• As inputs are Groovy expressions, all literals must be enclosed in quotes.
• If property is defined for current deploy instance (not test instance) then you do not have to qualify it.
  • For example, "-P EndPoint="+FLEXDEPLOY_SERVER_HOSTNAME +":" + FLEXDEPLOY_SERVER_PORT + " -P Database=" + FDJDBC_URL
  • In this example, FLEXDEPLOY_SERVER_HOSTNAME, FLEXDEPLOY_SERVER_PORT, FDJDBC_URL are defined on current deployment instance and hence we did not have to use Instance code prefix. But if you used TOMCAT_FDJDBC_URL it will work as well.
• If you are trying to use an encrypted property like a password then it may not be available here. In such situations, you can use replacement variables in your test files or command line arguments. Whenever you use property replacement or command line variables, they must be qualified using deploy instance code.
  • For example, in case of SoapUI, you can pass arguments like this to use password property (where TOMCAT is the instance code). "-P EndPoint="+FLEXDEPLOY_SERVER_HOSTNAME +":" + FLEXDEPLOY_SERVER_PORT + " -P Database=" + FDJDBC_URL + " -p\$TOMCAT_FD_JDBC_PASSWORD". Here we use \$ to make sure that this does not get evaluated in Groovy and is passed as environment variable to underlying command line call.
  • In this example, we are passing Unix environment variable syntax (assuming running on Unix) for password, and we need to qualify using instance code in such cases.