Forum Discussion

Liberty_Informa's avatar
Liberty_Informa
Regular Contributor
13 years ago

Project Property manipulation

Hi Admin

We use web based tool for doing daily smoke testing of our web services. The web based tool is also used by developers to kick off tests manually by selecting 2-3 choices.

One of the choices is to select 'target Environmen't. It is a drop down on the web page having range of all environments that we have. For development environment, we have 4 instances like dev-a, dev-b and so on. User can select any target environment and select test project of his/her choice to execute tests.

In order to change the target environment selected by the user, we were hacking into the soapUI project xml file and changing targetEnv Project property value with the that of selected by the user. This hacking was required because in the Project load script I take certain decisions based on the value received in the target environment. I don’t know is that a right approach or not but it works very well.

My question to you is – is it possible to tell soapUI project the target environment value without hacking into the soapUI project xml file? See below I am also passing tergetEnv as one of the parameters to the testrunner. 

$TESTRUNNER -r -I -j -f$setupReportHome [b]-PtargetEnv=$env[/b] -t$SOAPUISETTING $SETUPPROJECT > $MONKEYHOME/logs/$RUNDIR/SetupProject/$setupResultFile 2>&1


When we pass targetEnv as a parameter does that replace default project property value and load script receives replaced value? I think it is not.

What is the best way to handle this kind of situation?

Again with the composite project it is some other file (setting.xml) to hack into as soapUI project xml file doesn’t exists for the composite project.

5 Replies

  • nmrao's avatar
    nmrao
    Community Hero
    13 years ago
    I just want to share what i know the other way for running the tests on multiple environments. Below may more or less to what you are doing.

    For each service interface level, using the endpoint url value as a property instead of server, port. And this property is put in a property file. For each environment, will maintain separate property file.
    For eg:
    Using ${#Project#ENDPOINT_URL} at service interface.

    soapui.properties
    ENDPOINT_URL=http://myhost:myport/service1

    And in the load script, will load the properties from the above file, file name is read as System.getProperty('soapui.property') and pass argument -Dsoapui.property=<filename> to testrunner.

    Server name, port are an example, you may use as many number of properties as needed.
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    13 years ago
    Thanks @mnrao for taking time to understand the issue and giving solution on that lines.

    I understand what you are saying. I was thinking on similar lines after posting this question. I would like to confirm you that we are already using project property variables in order to make endpoints generic.

    For each environment, will maintain separate property file.


    Can you shed some light on why do you think we would require separate property files?

    What I am thinking is to have single common property file created each time. Our tests work as follows:

    1. User initiates tests using web interface
    2. Request comes to shell script for processing. There I can build property file and create at a specific location shared by all test projects
    3. In the soapUI project load script, load project properties from the property file
    3. Use property values to take certain decisions in the project load script.
    4. All endpoints anyway using project property variables

    When user wants to run tests in the tool itself, project load script will use default project properties (may be can load default properties again from a property file). Environments feature would be used to run tests on various environments.

    How it sounds?
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    13 years ago
    You guys are awesome!

    Do you think with the E parameter, project load script will pick up appropriate project properties? I read service header information in one more project property based on the target environment. The service header is further used as a property expansion in all the requests. This was required because we have separate request header specific to each environment.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    13 years ago
    Hello there,

    Yes, if it is configured to work that way in the environment then it should pick up the appropriate project-properties as expected. Did you manage to get it to work?

    Best regards,
    Mikael
    SmartBear Sweden