Forum Discussion

leandropoblet's avatar
leandropoblet
Frequent Contributor
8 years ago

Non-standard ways of using TestComplete for building test cases

Hi all,   I'm working on this concept to make use of TestComplete in a different way. Instead of adding test cases, steps to those test cases inside my project I'd like to have one "step" per test ...
  • tristaanogre's avatar
    tristaanogre
    8 years ago

    I'm with baxatob... what you've described is not exactly a non-standard way of using TestComplete.  Your original post describes, essentially, what I started doing years ago with POS product that I was testing.  Logging in was a function, navigating to the sales screen was a function, selecting a product for sale was a function, tendering a payment was a function, etc.  Then, creating a test case was just using the building blocks to put together different test scenarios into separate functions.  

    This is actually, one of the preferred methodologies in automated testing, not just with the TestComplete tool.  You modularize your code (even if you're doing KeywordTests, you can do this) and then build your test cases out of those modules.  It is actually one step away from going with something more data-driven in a framework where your data consists of the scenarios and the test "steps" to be executed and then you run a driver to read the data and execute the steps based upon the data source.  Changing a test case in that type of setup is then simply a matter of adjusting the data to reflect the desired changes.  Adding a test case is simply adding new rows to your data and so on.  

     

    What a lot of people do when it comes to using TestComplete to create test cases is all the code for a test case is contained within the test case... which ends up with a lot of duplicated code all over the place and a maintenance nightmare. As baxatob said, going modular like you are reduces the duplicated code.  But even having several test cases like TestCase1, TestCase2, TestCase3, each one calling "StartApplication" is, effectively, duplicated code.  Each test case "looks" the same, essentially.  Code wise, it makes the most sense to have a function for each step and then one function to read data to execute those steps in a configured order.  Code is reduced by an exponential factor and your primary maintenance for test cases is data entry and your code maintenance is simply maintaining your step-functions as your application and testing needs change.

     

    There are a LOT of ways of using TestComplete, some more common than others... what is probably the more pertinent question is what are "best practices" for test automation in general and how does TestComplete fit into those best practices.  You are on a good path, I think, towards utilizing TestComplete in an efficient manner and implementing those best practices.

tristaanogre's avatar
tristaanogre
Esteemed Contributor

I'm with baxatob... what you've described is not exactly a non-standard way of using TestComplete.  Your original post describes, essentially, what I started doing years ago with POS product that I was testing.  Logging in was a function, navigating to the sales screen was a function, selecting a product for sale was a function, tendering a payment was a function, etc.  Then, creating a test case was just using the building blocks to put together different test scenarios into separate functions.  

This is actually, one of the preferred methodologies in automated testing, not just with the TestComplete tool.  You modularize your code (even if you're doing KeywordTests, you can do this) and then build your test cases out of those modules.  It is actually one step away from going with something more data-driven in a framework where your data consists of the scenarios and the test "steps" to be executed and then you run a driver to read the data and execute the steps based upon the data source.  Changing a test case in that type of setup is then simply a matter of adjusting the data to reflect the desired changes.  Adding a test case is simply adding new rows to your data and so on.  

 

What a lot of people do when it comes to using TestComplete to create test cases is all the code for a test case is contained within the test case... which ends up with a lot of duplicated code all over the place and a maintenance nightmare. As baxatob said, going modular like you are reduces the duplicated code.  But even having several test cases like TestCase1, TestCase2, TestCase3, each one calling "StartApplication" is, effectively, duplicated code.  Each test case "looks" the same, essentially.  Code wise, it makes the most sense to have a function for each step and then one function to read data to execute those steps in a configured order.  Code is reduced by an exponential factor and your primary maintenance for test cases is data entry and your code maintenance is simply maintaining your step-functions as your application and testing needs change.

 

There are a LOT of ways of using TestComplete, some more common than others... what is probably the more pertinent question is what are "best practices" for test automation in general and how does TestComplete fit into those best practices.  You are on a good path, I think, towards utilizing TestComplete in an efficient manner and implementing those best practices.

leandropoblet's avatar
leandropoblet
Frequent Contributor
8 years ago

Hi all and thanks for your replies.

 

Both baxatob and tristaanogre got exactly the point and just made my life a lot easier! 

 

tristaanogre you lost me a bit here: 

 

tristaanogre wrote:

It is actually one step away from going with something more data-driven in a framework where your data consists of the scenarios and the test "steps" to be executed and then you run a driver to read the data and execute the steps based upon the data source.  Changing a test case in that type of setup is then simply a matter of adjusting the data to reflect the desired changes.  Adding a test case is simply adding new rows to your data and so on.  

 

Code wise, it makes the most sense to have a function for each step and then one function to read data to execute those steps in a configured order.  Code is reduced by an exponential factor and your primary maintenance for test cases is data entry and your code maintenance is simply maintaining your step-functions as your application and testing needs change.

 

 

I'm starting today turning those functions into modules and calling them. I though this was closer to a bad practice rather than a good one.

 

Thank you again for this massive game changer for me.

 

Marsha_R Yes you got it right. It was on the go and to make it very obvious to anybody reading the post what was the intention behind. I'll try and come with a better name next time. 

  • Colin_McCrae's avatar
    Colin_McCrae
    Community Hero
    8 years ago

    I take it a step further than TestComplete test cases.

     

    I use a keyword and data driven framework. Each input line calls a function. I guess that would be a test "step". Although, it's not really a TestComplete "step" in the true sense of the word as one function may generate several entries to the TestComplete log. But I also do my own custom logging and reporting, so this doesn't really matter.

     

    But then I enclose a series of these "steps" within calls (which are pretty much TFS Start <Case ID Date> and TFS End) to TFS. This ties a series of "steps" to a test "case" as set out on our test management system.

     

    Makes sense to do it this way as most "steps" can be re-used many times over numerous "cases".

     

    In my case, the majority of the "steps" are calls to handler functions. And the handler functions each deal with a certain type of control. There are other calls the "steps" can make. These tend to be slightly more specialised and/or application specific. But the majority of the handler functions can also be re-used on any other application written in the same language as they address controls directly. The location, type of control, action to take, data required, and expected results are all provided by the input data.

     

    Gives me maximum flexibility and re-use.

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

    tristaanogre you lost me a bit here: 

     

     

    Sorry. :) 

    What I did was describe to you the framework that I developed a bit ago.  Nothing huge but certainly a way of doing things that you might have considered "non-standard".  In essence, what Colin_McCrae described is close to what I'm doing but not quite to the granular level that he has.  I presented it in a webinar recently that you can view here but I do not present it as the only way to do such things. Basically, instead of a routine like

    function sellSomething() {
    Login('user', 'password');
    Navigate('sales screen');
    SelectProduct('item 1');
    TenderPayment('cash', '20.00');
    Logout();
}

    I have a set of data tables.  One table is the list of test cases indexed by an integer.  The other table is a list of "steps" that are associated with those test cases.  The function above would be one of those test cases.  Each module call in it would be  a step in the second table. Using DDT objects, I iterate through the first table, grab a test case, then build in memory the list of "steps" from the second table and then run them in order. I record the results, dispose of the data in memory, and go to the next set of records. So, the code itself consists of those individual modules and then a few routines of code to read the data and execute the modules. Changing a test case, as mentioned, is then not a matter of changing lines of code but simply changing the information stored in the data tables.