Forum Discussion

emmanuelflores's avatar
emmanuelflores
Occasional Contributor
8 years ago

Loading or referencing environment properties

Hello, I'm new to Ready API and SOAPUI NG in general. We're still trying to figure out best practices for various thing, in particular VCS. Our tests require a username password, however, we don't want to check in those values into our repository. One possible solution we were thinking about is having a properties file that never gets checked in, but lives in a directory SOAPUI can reference and load on application start up. Is this something SOAPUI can do?

 

If not what are the other alternatives? What are some of the best practices on handling credentials, e.g., username, password, keys, in test cases and repository? 

 

Appreciate any help thrown my way. 

  • gilugopi's avatar
    gilugopi
    8 years ago

     

     

    Actually Global Properties work well with environments

    And Environment settings are not under settings.xml, its under each projects xml file

     

     

    Lets say you create two different global properties

    envAPassword :  envAPasswordValue

    envBPassword :  envBPasswordValue

     

    Now you need a password property at the project level to show up in environments, let's call it projectPassword

     

    You need to environment settings

    1. select envA and need to specify projectPassword value as ${envAPassword}

    2. select envB and need to specify projectPassword value as ${envBPassword}

     

    Thus global properties flows seamlessly into your environment.

     

     

     

     

  • gilugopi's avatar
    gilugopi
    Contributor
    8 years ago

    Best thing I could think of is very similar to what you already described.

     

    1. List out these user ids and passwords as Global Properties. Since global properties reside in your soapui-settings.xml and specific to each user. Normally settings.xml remain outside your source code management tool.

     

     Since it's global, it can be accessed at a project level, test suite level, test step level

     

    2. Now global properties can be stored in a properties file and can be loaded using GUI or as command line argument to testrunner.sh or testrunner.bat.

     

    Regards,

    Gilu Gopi

    • emmanuelflores's avatar
      emmanuelflores
      Occasional Contributor
      8 years ago

      I didn't realize there were global properties as well, however I'm not sure it'll work out for Environments settings. If we want to switch from envA to envB, we need to reference the credentials for envB. 

       

      This does lead me to wonder if not checking in the settings.xml file for a Project would have the same impact. It seems like that's where the environment settings are saved.

      • gilugopi's avatar
        gilugopi
        Contributor
        8 years ago

         

         

        Actually Global Properties work well with environments

        And Environment settings are not under settings.xml, its under each projects xml file

         

         

        Lets say you create two different global properties

        envAPassword :  envAPasswordValue

        envBPassword :  envBPasswordValue

         

        Now you need a password property at the project level to show up in environments, let's call it projectPassword

         

        You need to environment settings

        1. select envA and need to specify projectPassword value as ${envAPassword}

        2. select envB and need to specify projectPassword value as ${envBPassword}

         

        Thus global properties flows seamlessly into your environment.