Forum Discussion

sriram_sig's avatar
sriram_sig
Contributor
6 years ago

What would be a good approach to build a framework for data driven testing

I'm trying to build a framework and working on ways to maintain test data in a effective manner. So thought of asking some suggestions here to see if any testcomplete offers something to make this ea...
Data-Driven Testing
Scripting
  • tristaanogre's avatar
    tristaanogre
    6 years ago

    To answer your first question:

    I don't map the parameters of the test case to fields on the screen.  I simply parse them out into individual values and pass them in to the method/function that I'm calling.  So, the parameters MAY correspond to a field on the screen... or not.  All depends on how the test case is coded. There's a master loop, I'm assuming, that parses the spreadsheet into the different test cases.  How are you executing the test case?  Is that being done in some sort of switch statement or are you using some sort of "eval" or "Runner.CallMethod" means?

     

    In any case, what I would do is use the aqString List methods (GetLength, GetListItem, etc) to populate an array of the different parameters.  JavaScript then allows you do so something like

     

    methodCall(...parameterList) where parameterList is the array.  The ... auto-expands the array which, effectively, passes the parameters into the method in the order in which they are found in the array.

     

    The framework structure I prefer is that, rather than having the data being driven by test case is that I have a two-table approach.   Table 1 is the driver that gives the list of test cases to execute.  Table 2 contains the "steps" mapped via testcaseID to table 1 to indicate what steps to execute and in which order to execute the test case.  Something like this:

    TABLE 1

    TestCaseID, Description

    1, CreateEvent Test 101

    2, CreateEvent Test 102

    3, CreateNotification

     

    TABLE 2

    StepID, TestCaseID, StepName, SupportingData, Description

    1, 1, OpenApp, blah|blah

    2, 1, LogIn, blah|blah

    3, 1, GoToEventCreate, blah|blah

    4, 2, OpenApp, blah|blah

     

    and so on....

     

    That allows me a bit more modularity and granularity to construct test cases using something more "plain language" as well as minimizing the shear volume of parameters you may need to deal with.

tristaanogre's avatar
tristaanogre
Esteemed Contributor
6 years ago

I personally prefer the first method.  The reason being is that you can do a lot more in the way of specific tweaking of execution to fail out of test cases, control the flow with exception handling etc.

As for your problem with columns, data, etc...  The way I handled that in the past was that I had a single column called "SupportingData" which had values separated by vertical pipes.  Using the https://support.smartbear.com/testcomplete/docs/reference/program-objects/aqstring/getlistitem.html method and other supporting methods, I used that way to just parse out the parameter values for the functions rather than having to have a different column for each parameter.

 

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    6 years ago

    Oh, and if I can add that I prefer CSV over Excel.  CSV is a lot more portable.  You don't need to have a specific program to edit a CSV file.

  • sriram_sig's avatar
    sriram_sig
    Contributor
    6 years ago

    Thank you! I'm curious to know using the aqstring method how do you determine which data would correspond to a field on the UI. If it is a user form with 10 fields, what would be a good way to map the items in the list to its respective field. Also would like to know if your framework maps each testcase to a single method 

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      6 years ago

      To answer your first question:

      I don't map the parameters of the test case to fields on the screen.  I simply parse them out into individual values and pass them in to the method/function that I'm calling.  So, the parameters MAY correspond to a field on the screen... or not.  All depends on how the test case is coded. There's a master loop, I'm assuming, that parses the spreadsheet into the different test cases.  How are you executing the test case?  Is that being done in some sort of switch statement or are you using some sort of "eval" or "Runner.CallMethod" means?

       

      In any case, what I would do is use the aqString List methods (GetLength, GetListItem, etc) to populate an array of the different parameters.  JavaScript then allows you do so something like

       

      methodCall(...parameterList) where parameterList is the array.  The ... auto-expands the array which, effectively, passes the parameters into the method in the order in which they are found in the array.

       

      The framework structure I prefer is that, rather than having the data being driven by test case is that I have a two-table approach.   Table 1 is the driver that gives the list of test cases to execute.  Table 2 contains the "steps" mapped via testcaseID to table 1 to indicate what steps to execute and in which order to execute the test case.  Something like this:

      TABLE 1

      TestCaseID, Description

      1, CreateEvent Test 101

      2, CreateEvent Test 102

      3, CreateNotification

       

      TABLE 2

      StepID, TestCaseID, StepName, SupportingData, Description

      1, 1, OpenApp, blah|blah

      2, 1, LogIn, blah|blah

      3, 1, GoToEventCreate, blah|blah

      4, 2, OpenApp, blah|blah

       

      and so on....

       

      That allows me a bit more modularity and granularity to construct test cases using something more "plain language" as well as minimizing the shear volume of parameters you may need to deal with.

      • sriram_sig's avatar
        sriram_sig
        Contributor
        6 years ago

        Thank you very helpful. I'm using the Runner.CallMethod to execute cases.

        I think it is better to follow the two-table approach, makes it easier