Forum Discussion
I like to use a data/table driven model where the driver of what tests to run, the contents of the tests (individual steps and parameters), and the order in which they are executed are stored externally from the automation code itself. I like to use CSV files for that data because they are portable and easily editable by any user with any variety of tool.
The script code consists of "atomic" steps, each one a class in Javascript which has properties corresponding to the data needed to execute the step and a method for the actual execution. A test case is then constructed in code from the CSV data to be an array of instances of the steps. A test case is executed then simply by traversing the array and executing the objects' primary methods in the designated order. Rather than using Test Items to build the report and execution, there's a minimal number of test items:
1) Reads the data and builds the test cases from the CSV files
2) Traverses the arrays and executes the tests
3) Cleans up the automation and any finalization routines.
Reporting is built from log entries using AppendFolder/PopFolder etc., to build a report based upon log rather than on the built in TestComplete reports. Others have adapted this to also write out reports to CSV, XML, or other formats internally.
The pro that I've found for this method is that you can have a few people whose job it is to maintain the highly object oriented, modularized code. If the test case requires a minor change in work flow, rather than needing to redo a whole test case, you only need to modify code for the individual step/class. The more "atomic" the steps, the easier it is to maintain. Additionally, with sufficient documentation, ANYONE can build a set of test cases for execution without having to know anything about TestComplete or the code involved. They just populate a set of CSV data files and click a desktop icon to run the tests in TestExecute.
tristaanogre Thank you for sharing your thoughts and workflow!
>> If the test case requires a minor change in work flow, rather than needing to redo a whole test case, you only need to modify code for the individual step/class.
That is great, definitely makes test maintenance much easier and safe. I try to do something similar with my functions by making re-usable functions with user parameters that can be used in all scenarios. Makes the later part of making and updating tests much easier.
What do you mean by "atomic" steps though? Does that mean breaking the steps into even smaller steps which makes assembling part more flexible?
- BenoitB5 years agoCommunity Hero
atomic means that u can't slice in smaller action, more initial work because sometimes lot of primitives, lot of intellectual work to keep all in mind and here good source documentation is important, so lot of time before delivering starting to test .. but after you have just to call assemblies of these primitives and you can do everything very quickly
high learning curve but reusability max, even between different apps
its the way of building a framework
Related Content
- 11 months agojustinrose
- 2 months agoj54321ohn
- 2 years agonzStacy
- 4 years agonishant4121988
Recent Discussions
- 4 hours agoSvetaG