Forum Discussion

Lee_M's avatar
Lee_M
Community Hero
4 years ago
Solved

String Default Values

I have a persistent variable of type String   I have 'unset'/deleted the Local Value and then perform a KW log message on the variable I expected to see the default value but instead, I see a b...
  • nmrao's avatar
    nmrao
    2 years ago

    Kimdoengart 

    Yes. It is possible to find that.

    I believe that the above code snippet is of script assertion of the Soap Request type test step, but not Groovy Script test step.

     

    Here it goes:

     

    import com.eviware.soapui.impl.wsdl.teststeps.WsdlTestRequestStep
if (context.currentStep instanceof WsdlTestRequestStep) {
 //Your code goes inside of this if block

}

     

     

Lee_M's avatar
Lee_M
Community Hero
4 years ago

What is the point of having a default value then?
It is like having a second variable value in this case

I set up a string variable in the project and then test if a value has been entered during the run - I have to test every time for an empty string too now

AlexKaras's avatar
AlexKaras
Icon for Champion Level 2 rankChampion Level 2
4 years ago

Hi,

 

> What is the point of having a default value then?
The roots of this functionality are back to the projects opened in a Shared Mode. Unfortunately, this extremely useful functionality is broken for several years (major TestComplete versions) and I barely hope it will be restored (Case #00126077)

When a project was opened in a shared mode, all its project variables became per-computer personalized. I.e. if you open your test project in the shared mode from box A, the value of the dataPath project variable could be c:\testData\ but if you open the same project from box B, the value of the same variable could be d:\dataForMyTests\.

In the above scenario, when the project was opened in the shared mode for the first time on the given box, all project variables got their local values from default ones. So in this case default value of the project variable had exactly that meaning that you are expecting.

Unfortunately, as I said, the above scenario with its extensions like customized set of enabled Test Items (that personally I widely used) does not work anymore and thus your version of reply ("It is like having a second variable value in this case") is much closer to reality. The only convenience is that you do not need to have separate variables for actual and default value but can have one variable that keeps both actual and default value.

 

sonya_m : Just for your information. Case #00126077...

 

  • Lee_M's avatar
    Lee_M
    Community Hero
    4 years ago

    AlexKaras 

     

    Thanks for this information, very insightful.

    This makes a lot of sense now why there are 2 values, not helpful to my current situation but clear as to why there are 2.

     

    For now, we are left with 2 values that serve no more purpose other than a developer description and a possible manual reset reminder value

  • JuliaBernikova's avatar
    JuliaBernikova
    Icon for Alumni rankAlumni
    4 years ago

    Hi AlexKaras,

     

    Thanks for replying to Lee!

     

    It looks like some Shared Mode feature does not work as expected for you. I'd like to understand exactly what goes wrong - if the functionality does not work as stated in the documentation, our product team will investigate it.

     

    Lee originally asked about the default values of persistent variables. As I can see, they work exactly as you described (see this GIF).

     

    I've also reviewed case 00126077 where you discussed the customized set of test items feature with our team. The case was submitted for TestComplete 11, and as I can see, our developers confirmed that neither of the versions after TestComplete 4 (released circa 2006) included this feature. So, it was decided to submit an enhancement request: https://community.smartbear.com/t5/TestComplete-Feature-Requests/Make-settings-for-the-project-opened-in-the-shared-mode-to-be/idi-p/105106. Thus, the conclusion was that the feature functions as expected.

     

    Could you please describe how you'd like to use Shared Mode and what issues you see with your scenario?

     

    • AlexKaras's avatar
      AlexKaras
      Icon for Champion Level 2 rankChampion Level 2
      4 years ago

      JuliaBernikova :

       

      Hi Julia,

       

      Thank you a lot for the follow-up with my case and recorded gif. Much appreciated indeed!

      Yes, I can confirm that for persistent variables shared mode functionality works as documented and as expected.

      However, I just double-checked it and can state that the same functionality does not work for temporary variables and Enabled setting for Test Items in the Execution Plan.

      I do not remember if temporary variables exist at the moment when I reported the case 00126077, but I am sure that the functionality for Test Items worked and I widely used it. I am practically sure that all this was for TestComplete version 4 and/or above.

       

      The use case for temporary variables and Test Items is exactly like for persistent variables that is demonstrated on your recorded gif :

      -- It is very convenient when the Default Value for the temporary variable and Enabled setting for every Test Item are customized when the project is opened in the Shared mode.

      -- If temporary variable is added to the project when the project is opened in the Shared mode, then the current (customized) value of the variable must be propagated to the local Default Value of the variable. I.e. the variable must have the same Default Value when the project is opened in the local mode;

      -- If Test Item is added to the project when the project is opened in the Shared mode, the local Enabled setting for this Test Item must be set to False. I.e. this Test Item must be initially disabled when the project is opened in the local mode. This is to lower the risk to break scheduled project execution in CI system when the project is usually opened in the local mode.

       

      Julia, please feel free to contact me directly so we may further discuss topics that are not clear enough.

       

      • JuliaBernikova's avatar
        JuliaBernikova
        Icon for Alumni rankAlumni
        4 years ago

        Hi Alex,

         

        Thanks for the detailed description of the scenario! However, it looks like the functionality not working for temporary variables and test items is expected.

         

        First, the way Shared Mode works currently, the Default Value of variables is never customized, the configuration only stores the Local Value. With temporary variables, there's simply nothing to store - they don't retain their values after the test run is over. So, their Local Value is always equal to the Default Value no matter how this value may change in the test. This is also the reason why the Local Value column is not shown for temporary variables.

         

        Now, as for storing the "Enabled" property for the test items, I can see how this could be useful. However, I haven't found any mentions of this feature in the documentation for TestComplete 4. Our support team also confirmed it when working on case 00126077 that this feature was not a part of the later versions.

         

        It might be that the feature you described was available in older TestComplete versions (TestComplete 2 or 3, maybe). However, it's not a part of the product right now, so the Shared Mode functionality seems to work exactly as expected.

         

        As you know, our product team welcomes any feedback, but the number of enhancements we can implement is limited. So, the team tries to implement the ideas that would benefit most customers. Unfortunately, right now it seems that the scenario we discuss is not exactly a common one, so no enhancements are planned at the moment.

         

        As a way to prevent breaking project execution from a CI system, I'd recommend either specifying exactly what test items should be run instead of running the whole project. Or, if the number of test items is too big, you can use source control to make sure no local changes affect the project in the remote repository used by the CI system.