Forum Discussion

tim_faron's avatar
tim_faron
Contributor
11 years ago

Add Script Extensions Programatically

With our code being in source control, we like to be able to run some sanity against a merge branch and then when it's validated pull it to an automation branch for regression.

 

This being the case, on my Windows machines, I have a directory structure for each branch ... 

 

As of right now I only run my tests from one branch becuase I utilize many script extentions and I don't want the same extension from multiple locations to exists in the dialog.

 

Is there a way to set these extension programatically, this would allow me to set them to a particular location depening on where I am running my tests from

  • NisHera's avatar
    NisHera
    Valued Contributor
    11 years ago

    would you mind tell why do you have many version of script extentions?

    For me script extentions are used to handle common functonalities eg. log on etc.

     

    • tim_faron's avatar
      tim_faron
      Contributor
      11 years ago

      We exclusively script our framwork and testcase in jScript. We are not using NameMapping/Alias so we define the our common functions like you mentioned and our product functions in script extentsions and write out testcases as scripts. One reason is to avoid //USEUNIT everywhere and to make things more modular.

       

      Regardless, even if I just used for common functions, in our environment we source control out code initially to a branch where we want to run tests and validate the code  before pulling it into production..

       

      So with TestComplete I might want to run initially with code from c:\merge and for regression i want to run from c:\automation but i don't want to manually have to change script extensions path

      • Ryan_Moran's avatar
        Ryan_Moran
        Valued Contributor
        11 years ago

        Hi Tim,

        Just to give you an idea of how we handle this (not saying you're doing anything wrong)...

        Using SVN we just update to a prior revision number...If the new changes work for us then we grab the latest version.

        No merging or splitting required. However, we have a small set of scripts for the framework and everything else is data-driven.

        Sounds like you may also benefit from reading about Data-Driven testing to make your tests more manageable.