Forum Discussion

HeikoStudt's avatar
HeikoStudt
Occasional Contributor
10 years ago

Testrunner, Script and "isCommandLine"

[Edit: Clearing up quite a bit] Hi,   I am using the latest SoapUI 5.2.1 with its testrunner.bat   Manual steps should be ignored from commandline - at least according to the source code of Soap...
isCommandLine
testRunner
HeikoStudt's avatar
HeikoStudt
Occasional Contributor

The "isStandalone" seem to be false for TestRunner and true for SoapUI (GUI).

However, I did not read the source code for understanding what "isStandalone" should mean, there are no comments whatsoever.

 

 

MFG (Best regards)
Heiko Studt

kondasamy's avatar
kondasamy
Regular Contributor
10 years ago

So, just to make your code work, you could probably try the below script using 'isStandalone' instead of 'isCommandLine' like this,

 

if (!isStandalone) {
    log.info("in cmdl");
    testRunner.gotoStepByName( "GetStates is Empty" );
}

And I guess the behavior of 'isCommandLine' currently you are experiencing should be a bug!

 

Thanks,

Samy

  • HeikoStudt's avatar
    HeikoStudt
    Occasional Contributor
    10 years ago
    kondasamy wrote:

    So, just to make your code work, you could probably try the below script using 'isStandalone' instead of 'isCommandLine' like this,

     

    And I guess the behavior of 'isCommandLine' currently you are experiencing should be a bug!

     

     

    Yes, the workaround with isStandalone is working in my project.

    I absolutely agree, that the isCommandLine has to be corrected, as ATM all manual steps will fail in testrunner.bat.

    Can someone please point me to the bug tracking system of SoapUI? A quick google search did not find one.

     

     

    MFG (Best regards)

    Heiko Studt

    • kondasamy's avatar
      kondasamy
      Regular Contributor
      10 years ago

      I don't think you can raise a bug for SoapUI Open Source. But, if you face this issue in SoapUI NG, you can raise a ticket here - http://support.smartbear.com/product-list/

       

      Thanks,

      Samy

       

      Did my reply answer your question? Give Kudos or Accept it as a Solution to help others, Thanks. ↓↓↓

      • HeikoStudt's avatar
        HeikoStudt
        Occasional Contributor
        9 years ago

        By the same bug, the -enableGUI parameter and whatever initGCTImer() does is broken as well. (see below).

         

        For the real SoapUI developers: It will fixes plenty of bugs in the Commandline-Testrunner if you fix this issue. Thank you! :-)

         

         

        The problem lies in the AnalyticsHelper:

        private static boolean analyticsDisabled() {
                Settings settings = SoapUI.getSettings();

        which in turn creates a "DefaultSoapUICore" as there was none initialized before

        which in turn sets isCommandLine to false.

         

        As the AnalyticsHelper opens some GUI component if you did not enable/disable the analytics before, this is already a bug.

         

        However - without analytics - in AbstractSoapUIRunner.run() the isCommandLine field is set twice.

        public final boolean run() throws Exception {
                if (SoapUI.getSoapUICore() == null) {
                    SoapUI.setSoapUICore(createSoapUICore(), true);
                    SoapUI.initGCTimer();
                }

        createSoapUICore() creates the DefaultSoapUICore which will set isCommandLine to false.

        setSoapUICore is resetting to true just afterwards...

         

         

        In my uninformed opinion the bug was inserted as the analytics were put inside. As I hate those analytics anyway, I will disable it in my source permamently... :-)

         

        11:01:35,949 INFO  [log] isCommandLine:true
        11:01:35,951 INFO  [log] isStandalone:false

         

        Voilà! :-)

         

         

         

        MFG
        Heiko Studt