Forum Discussion

Manfred_F's avatar
Manfred_F
Regular Contributor
8 years ago

TE: configure test sequence in external file

I'd like to control TE's test run by an external file.

In the file, the testing engineer selects from the available tests to execute the ones he Needs to.

 

Has anybody done this before?

My question: how can I tell TE where to find the config file? I don't want to hardcode it, because I Need portability.

I start TE's test run from a link located in a certain control Directory. It would be great If TE could determine this Directory and search there for the config file.

Is this possible?

 

An alternative would be to Hand in a free comandline Parameter, which seems not to be possible..

9 Replies

  • baxatob's avatar
    baxatob
    Community Hero

    Project.Path will return the path to your project directory. So you can create some sub-folder /Config and store there configuration files, or even put your file in the project root.

     

    Something like:

    path_to_config_files = Project.Path + '/Config'

     

  • Ravik's avatar
    Ravik
    Super Contributor

    This may help you ......

     

    Create a Function/Sub in TestComplete which is read your config (Text file or excel file) data and supply it to necessary TestCases.

     

    Lets say you have 100 TC in your TestSuite but you want to run specific data base on the execution flag mention(Y/N) in configuration file. your function should read Y/N and Supply it to TestCase.

     

     

    Run that function (.vbs or .js or .py) in your TestExecute (Command Like -  

     

    "C:\Program Files (x86)\SmartBear\TestExecute 11\Bin\TestExecute.exe" "C:\Work\My Projects\MySuite.pjs" /r /p:MyProj /t:"Script|Unit1|Main"

     

     

     

     

     

     

    Function TCConfig(strDatasheetPath)

     

    Set objExo = CreateObject("Excel.Application")

    Set objWbo = objExo.Workbooks.open(strDatasheetPath)

    objWbo.Application.Visible = True

    set objwso = objWbo.Worksheets("Sheet1")

    intRows = objwso.UsedRange.Rows.Count

    intCols = objwso.usedRange.Columns.Count

    For intRow = 2 to intRows

    'read Test Case Execution flag, test Case Execution flag in 1st column

    strExecutionFlag = objwso.Cells(intRow,1)

    If uCase(strExecutionFlag) = "YES" Then

    'read Test Case Name here, test Case in 2nd column

    strTestCaseName = objwso.Cells(intRow,2)

     

    For introw = 1 to intRows

     

    'Take Required action here for your test case

     

    Next

    End If

    Next

     

    End Function

     

     

    "C:\Program Files (x86)\SmartBear\TestExecute 11\Bin\TestExecute.exe" "C:\Work\My Projects\MySuite.pjs" /r /p:MyProj /u:Unit1 /rt:Main"

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero

      I do exactly this.

       

      All my tests are keyword and data driven from Excel sheets.

       

      But I wrote my own framework (all in Script Extensions) to do so. Using the DDT Excel driver wasn't flexible enough for me. Everything can be toggled on or off by the user. It also does everything relative to the project path (as mentioned by baxatob) so the whole project is completely portable. When run, it expects the project to contain a "working" directory containing and input, result and log folders. If they are not present, it creates them, logs an appropriate message in the newly created log folder and then either continues the run, or ends, depending on which parts of the working directory were missing. (Obviously, it can't continue if there is no input folder!)

       

      But like I say, this is an entire framework built from scratch. Any project making use of it (ie - all of them!) then only has to have a single, fairly short, driver script in order to run. On top of that I have a few libraries of generic functions - ones used for application control rather then part of framework so not in script extensions. And the final layer is project specific script files and the name map.

       

      Took a bit of work to put it all together, but it's worth it now.

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor

        The framework that I presented in the October TestComplete Academy 301 does pretty much the same thing that Colin_McCrae described, albeit in a different implementation and not nearly so robust. Generally speaking, there are probably any number of ways of doing what you want done.

        For example, let's say that you have a whole bunch of keyword tests, each one representing a particular test case. Every time you run the project, you don't necessarily want to run ALL your tests, just are targetted selection.  What you could do is create a different folder for each run configuration with either an Excel sheet or a CSV file in it.  Each row in the file would contain two columns.  Column 1 would be the name of the keyword test ('PageLogin', 'PrintFile', etc).  The second column would be a string of parameters to pass in, if necessary ("'myusername', 'mypassword'").  You would then write something like this (JScript/JavaScript).

         

        function runMyTests(testListFile) {
            var myTestList;
            try {
                myTestList = DDT.CSVDriver(testListFile);
                while (!myTestList.EOF()) {
                    if (aqObject.IsSupported(KeywordTests, myTestList.Value('TestName')) {
                        eval('KeywordTests.' + myTestList.Value('TestName') + '.Run(' + myTestList.Value('ParameterString') + ')');
                    myTestList.Next();
                }
            }
            catch (exception) {
                Log.Warning('Exception : ' + exception.message, exception.stack);
            }
            finally {
                if (myTestList != undefined) {
                    DDT.CloseDriver(myTestList.Name);
                }
            }

        Run this as the only TestItem in Project.TestItems for your project and, effectively, it will execute all the keyword tests in your project that you have configured in the indicated CSV file.  All you would have to do is pass in the necessary file name and path and you're good to go.

         

        Again, this is not the ONLY way to do it but it demonstrates another methodology to do what you're asking.  This just goes to show that, depending upon your need and skill, you can implement what you're asking in a variety of different ways. It is left to you, then, to determine what meets your needs best.