Forum Discussion

AdrieVanDijk's avatar
AdrieVanDijk
New Contributor
8 years ago

testrunner ignores the -t option

When I execute a soapui project on the command line with testrunner.sh on Linux or testrunner.bat on Windows, it seems to ignore the settings file that I specify with the -t option.

No matter what I specify, it always looks in the current directory for a file named soapui-settings.xml and when it is not found there, it looks in the user home directory for the same and when that too does not exist, it creates a new one in the user home directory.

I need this because for only some tests I need to use a proxy and a client certificate, which I have specified in a special settings file. When I put these settings in the standard settings file, its works.

I have googled for similar problems, but I seem to be the only experiencing this, so I must be doing something wrong.

Can anybody enlighten me? Thanks.

3 Replies

  • MV's avatar
    MV
    New Contributor

    Hi Adrie,

     

    You're not the only one experiencing this problem. I've encountered the same issue and no matter what I try, the -t argument is being ignored by the testrunner :(

    I also did not find any solution on the Smartbear forums or via Google. Did you manage to find any solution for this?

    • AdrieVanDijk's avatar
      AdrieVanDijk
      New Contributor

      Hi MV,

       

      It is a real bug. I spent quite some time on debugging soapui and I think something is wrong with the order of the different kind of initializations that are taking place. Apearantly, the developers don't read this forumk.

      Finally I decided to let it alone and use a workaround, which is: create a soapui-settings.xml with the required proxy settings and overwrite the existing settings before I call the testrunner. When I dont't want to use the proxy, I simply delete the settings and the testrunner will then create it again with the default values.

       

      Regards,

      Adrie

      • MV's avatar
        MV
        New Contributor

        Thank you for the update and possible workaround. To bad that there isn't a proper solution for this yet. I will probably also use the workaround of replacing the default settings.xml via a batch file or something before executing the tests.