| || |
TestComplete and Behavior Driven Development
Did anyone ever use TestComplete in a Behavior Driven Development context? If so, can you discuss your process and the code you had to write to handle the given/when/then structure automatically? Any comment is welcome.
Re: TestComplete and Behavior Driven Development
As far as I know, Behavior Driven Development is quite an abstract approach, and I'm not sure that there is a way to create a general converter which can be used to convert a set of native-language sentences describing requirements for TestComplete tests. However, it should be possible if you use only a limited number of entities which can produce a limited number of combinations (or there is a way to generate the needed conversion rules automatically for each combination).
TestComplete tests can be present as script units or keyword-driven tests. Since keyword-driven tests can only be generated via TestComplete's GUI and are not as flexible as scripts, you will need to use scripts. So, you will need to create a utility which takes a set of native-language data, parses the data (and checks for possible syntax errors), builds an abstract syntax tree (or a concrete syntax tree) and then converts the tree to a test script. That is, you will need to create a compiler for your specific purpose. Implementing such a utility can be a difficult task, and therefore, I recommend that you use one of the following approaches instead:
1. Use keyword-driven testing in TestComplete. This approach allows you to combine a set of predefined operations (such as mouse clicks, keystrokes, checkpoints and logging operations, etc.) the way you need. In this case, you will not have to parse anything, but your tests will be a combination of TestComplete operations, not custom entities specific to your application.
2. Create a number of small tests (either keyword-driven tests or test scripts) and associate each of the test with an entity in your application (you can use the object-driven testing approach for this purpose, see the "ODT Project Item" help topic for more information). If you use this approach, you will still need to create a kind of compiler which will process an input "program" file in a custom format and call the needed tests according to the "program" you passed. That is, control the execution order of the small tests (and, probably, change the execution order dynamically according to results of each test). However, in this case you will not need to create any script code lines in your compiler (you will just call the needed routine/keyword test, thus working with higher-level abstractions), which makes implementing such a compiler much easier.
The approach you choose depends on your programming knowledge and your testing scenarios.