Forum Discussion

leandropoblet's avatar
leandropoblet
Frequent Contributor
8 years ago
Solved

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.