Forum Discussion

AlexKaras's avatar
AlexKaras
Champion Level 3
8 years ago

Script Extension: When does the 'extension loading into memory' event occurs?

Hi,   From https://support.smartbear.com/testcomplete/docs/working-with/extending/script/creating/initialization-and-finalization-routines.html : "The initialization routine of a script is execut...
  • tristaanogre's avatar
    tristaanogre
    8 years ago

    As a test, I created a script unit for a script extension with just the following:

     

    var mySomething;

function getMySomething() {
    return mySomething;
}

function setMySomething(value) {
    mySomething = value;
}

function Initialize() {
    mySomething = 'this is the initial value';    
}

    I encapsulated this into an extension with the following Description.XML

     

    <ScriptExtensionGroup Name="TestThis">
    <Category Name="TestThat">
        <ScriptExtension Name="TestInitialization" Author="Robert Martin" Version="1.0">
            <Script Name="testExtensionInit.sj" InitRoutine="Initialize">
                <RuntimeObject Name="TestInit">
                    <Property Name="MySomething" GetRoutine="getMySomething" SetRoutine="setMySomething">Property description</Property>
                    <Description>Runtime object description</Description>
                </RuntimeObject>
            </Script>
            <Description>Script extension description</Description>
        </ScriptExtension>
    </Category>
</ScriptExtensionGroup>

    I then wrote this code:

     

    function blah() {
    Log.Message(TestInit.MySomething);
    TestInit.MySomething = 'New Value';
    Log.Message(TestInit.MySomething);
}

    The first time I run this code after starting TestComplete I get a log that looks like this:

     

     

    If I run it again without restarting TestComplete, I get the following:

     

     

    So...  the Initialization is executed at loading of TestComplete. The value in the variable persists beyond the test run so long as TestComplete has not been restarted.

    If you want a variable value to be initialized in a script extension at the start of a test run, I believe you'll still need to call specific code to initialize the value.

tristaanogre's avatar
tristaanogre
Esteemed Contributor

As a test, I created a script unit for a script extension with just the following:

 

var mySomething;

function getMySomething() {
    return mySomething;
}

function setMySomething(value) {
    mySomething = value;
}

function Initialize() {
    mySomething = 'this is the initial value';    
}

I encapsulated this into an extension with the following Description.XML

 

<ScriptExtensionGroup Name="TestThis">
    <Category Name="TestThat">
        <ScriptExtension Name="TestInitialization" Author="Robert Martin" Version="1.0">
            <Script Name="testExtensionInit.sj" InitRoutine="Initialize">
                <RuntimeObject Name="TestInit">
                    <Property Name="MySomething" GetRoutine="getMySomething" SetRoutine="setMySomething">Property description</Property>
                    <Description>Runtime object description</Description>
                </RuntimeObject>
            </Script>
            <Description>Script extension description</Description>
        </ScriptExtension>
    </Category>
</ScriptExtensionGroup>

I then wrote this code:

 

function blah() {
    Log.Message(TestInit.MySomething);
    TestInit.MySomething = 'New Value';
    Log.Message(TestInit.MySomething);
}

The first time I run this code after starting TestComplete I get a log that looks like this:

 

 

If I run it again without restarting TestComplete, I get the following:

 

 

So...  the Initialization is executed at loading of TestComplete. The value in the variable persists beyond the test run so long as TestComplete has not been restarted.

If you want a variable value to be initialized in a script extension at the start of a test run, I believe you'll still need to call specific code to initialize the value.

AlexKaras's avatar
AlexKaras
Champion Level 3
8 years ago

Hi Robert,

 

> the Initialization is executed at loading of TestComplete.

As I expected it to be... Not good...

Anyway, thank you a lot for all your efforts and provided evidence! Your reply answers my question exactly as I would like the answer to be. Thank you again.

Excuse me that you had to play with custom extension... - I hoped that you already have known the answer as you have dealt with script extensions a lot. (Maybe this is something that can be used in your upcoming training if you consider to compare properties in script extension with project variables.)

 

HKosova: Helen, could you please talk to help writers and discuss with them whether the mentioned help topic can be made more clear using the input from Robert?

  • HKosova's avatar
    HKosova
    SmartBear Alumni (Retired)
    8 years ago

    AlexKaras, I've passed your comments to the team. Thanks for the feedback!

     

    tristaanogre wrote:

    If you want a variable value to be initialized in a script extension at the start of a test run, I believe you'll still need to call specific code to initialize the value.

     ^^ This, optionally coupled with OnStartTest.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    8 years ago

    Hey, no problem, man.  I suspected the solution as I have used initialization routines before but I needed to make sure.

    In my case, I've used initialization routines to create SQL DB connections or to populate SQL connection strings so I don't need to make those calls in code.  These are things that I want to have persist all the time rather than having to set them once.

    And yes, after I wrote this, I figured that this would be a good bit to add to the webinar next Tuesday.  :)

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      8 years ago

      > this would be a good bit to add to the webinar 

      Good to hear this :)

       

      > I've used initialization routines to create SQL DB connections 

      Just a paranoid tester's ;) scenario:

      (At least for me) it is quite a common thing to have TestComplete running on the machine for several days without been closed/restarted. Machine even can be hibernated and restored back. There is a chance that database server can be restarted during this time thus invalidating the connection object that is kept in script extension. Most probably, the user will get (a strange) error when the script extension is used and the only way to get rid of this error is to restart TestComplete (or reload relevant script extension).

      Thoughts/comments ?

       

      (Again, maybe something worth to be mentioned on the webinar...)

       

      P.S. Well... It is my current understanding that because script extension cannot initialize itself on test run start, it must contain some method that must be called explicitly from test code. Considering this, it looks like that the only advantage of script extensions of runtime type that (script extension) require initialization over regular test code is that this script extension can be used from test projects that use different script languages.

      OK... Probably, need to think about this a bit more...

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        8 years ago
        AlexKaras wrote:

         

         

        Just a paranoid tester's ;) scenario:

        (At least for me) it is quite a common thing to have TestComplete running on the machine for several days without been closed/restarted. Machine even can be hibernated and restored back. There is a chance that database server can be restarted during this time thus invalidating the connection object that is kept in script extension. Most probably, the user will get (a strange) error when the script extension is used and the only way to get rid of this error is to restart TestComplete (or reload relevant script extension).

        Thoughts/comments ?

         

        No, totally legit observation.  It is something to remember that anything stored in a RunTime Object property persists until TestComplete (or TestExecute, for that matter) is restarted. So, if there are values that may become invalid over time, this is certainly something that needs to be taken into account. In my case, I don't keep my app up persistently.  TestExecute is run with the Exit commandline switch when we run a test and I shut down my IDE when I leave work for the day.  But, as you pointed out, not everyone does the same thing. :)

         

        AlexKaras wrote:

         

        P.S. Well... It is my current understanding that because script extension cannot initialize itself on test run start, it must contain some method that must be called explicitly from test code. Considering this, it looks like that the only advantage of script extensions of runtime type that (script extension) require initialization over regular test code is that this script extension can be used from test projects that use different script languages.

        OK... Probably, need to think about this a bit more...

        At least for those initialization routines, yes.  And, not just that it can be used in different languages but it does take some of the "work" out of the process of certain initialization processes that you need to have happen environmentally.  I used SQL connections as the example, but you could populate a property with some value you want to persist from your environment. For example, if you're running tests against a web app where your test environment may vary from machine to machine, your script extension could populate run time object property with the host name to be used on the current machine.  That way, no matter what machine you open the project on, you'll be guarenteed to have the correct host name (make it a read only property that is set internally by the initialization routine).

         

        Keep in mind, also, that the Initialization routine isn't limited to just runtime objects.  There are options that can be set via a script extension that could be intialized upon startup of TestComplete if you want to make sure that every environment has a particular set up.  Extensions that are involved with Log Actions may need to initialize connection strings or properties to interact with the external tool. So, quite a few applications. But again, the caveat is that a) that information is reset when TestComplete is restarted and b) the information persists so long as TestComplete is running.

         

        In your case, you are thinking about using a RunTime object property instead of a temporary project variable to hold a value.  There's still an advantage there.  As you mentioned, it allows you to use the runtime object and associated properties across multiple langauges (check out OutParameterWrapper for one such example). But, also, you don't have to repeat the code in multiple projects or bother with any USEUNIT or uses clauses. All your code for working with that variable, including the variable itself, is contained within the RunTime object so you can call it at will with any test case or test item without needing to import any code units.