KeywordTest or scripting?

My experience:  Keyword tests are excellent ways of creating tests visually with minimal code knowledge for interacting with OnScreen objects and creating checkpoints.  For testers who are not familiar with writing script code and need a way to create good, clean automation tests, Keyword Testing is an EXCELLENT way to go.



However, I ran into a recent example where a keyword test really does not do well for performing a task.  While it can be done, I've found that it is more efficient to create ADO SQL Query objects, pass in a string to the query, execute, iterate through the result, and report on the results, through script code.  To do all the string concatenations and such in keyword tests gets cumbersome and hard to follow.  Also, if you find yourself using a lot of Code Expressions or Code Snippets in your keyword tests, it might just be as easy to write those as Script and call them as scripts.



In some of the tests I'm building, I use a combination of the two.  I use the keyword tests for the onscreen interactions and use script code for some of the more complex tasks and for some of the custom validations that I need to do, blending the two, calling keyword tests from script and vice versa.

Thank you, Robert, I can agree with your points of view how to handle tests with tc.

I tend to write my tests more and more in scripts than in keywordtest. 





The idea about "ADO SQL Query objects" I don't really catch. 

Are your script-code in an external database that you get with the select-directive 

executing it with "evaluate" or something in that way?

It's more on the lines of testing certain features and functions that don't have a GUI but are driven off of data.  For example, we have an application that sends SMS Text messages to contacts based upon dates, times, and other things stored in an SQL database.  That application simply runs in the background with no GUI interaction.   In order to test it, I need to execute UPDATE and INSERT statements in the SQL database.  So, I use the ADO objects built in to TestComplete to create and execute queries and return ADO record set results.  This is doable with Keyword Tests but the amount of "hoops" I've had to jump through to do so with a Keyword Test made it extremely cumbersome compared to the relatively few lines of code I had to write for Script.



But, meanwhile, when it comes to adding new GUI interaction steps and such, it's VERY easy to select "On Screen Action" Operation, use the finder tool to find the component I want, and then select the method and now I have a whole new step.  And then, to parameterize it all and make it loopable with the wizard is VERY nice indeed.  Both features have their advantages and particular uses and I can't necessarily say "Only keyword tests" or "Only scripts".  For myself, I'm more comfortable with scripts since I started using TestComplete back at version 1.5 before Keyword Tests were available and so I'm used to doing everything in script code.  Others may find Keywords easier.  I think, though, in any testing team, you'll find that a blend of the two works very well to make for a nice set of automation.

this is the so called "data driven test" you are explaining off, isn't it?

this is one of my next topics to start with...





however, i wished that the relation between script and keywordtest would be the same like Delphi's DFM(GUI) and it's unit.

changing the DFM per dragging components on the form would change the source-code that i can change manually too.





beside this: tc don't find and therefore can't change text in the keywordtests with the finding dialog (ctrl +f)

this slows down production...

this is the so called "data driven test" you are explaining off, isn't it?  this is one of my next topics to start with...

Not really, no.  In the case of the app, what makes the app do anything is in the data.  So, if I want a new message to be sent, I need to actually insert data into the SQL database in a format that the app is expecting.  If I want message type A to send, I need to manipulate the data in the SQL so that the app that monitors that data then processes accordingly.  If my next test is to send message type B, I again need to manipulate the data.  There is no "on screen" UI to make those changes so I need to do them in SQL directly.



As another example, while DBTables checkpoints are good, there's a limitation to them.  Let's say I'm working against a database that I need to make sure of certain values being stored properly, one being the date that the data was entered.  Well, if I run the script today, that date will be today's date.  If I run it tomorrow, that date will be tomorrow's date.  There's no way to set up a DBTable checkpoint to tell it to use a regular expression to validate to make sure that the date in that column is today's date.  For that purpose, I have to write custom SQL queries and do comparisons that way with regular expressions or other methods to make sure the date is being properly stored.  DBTable check points work great with both keyword tests and scripts, but writing those custom SQL queries and custom comparison code is much easier done in script than in a Keyword Test.

however, i wished that the relation between script and keywordtest would be the same like Delphi's DFM(GUI) and it's unit.  changing the DFM per dragging components on the form would change the source-code that i can change manually too.

THAT would be cool as well.  However, what if I change the code behind the scenes in such a way that the KWT does not support or does not translate into KWT operations?  Right now, KWT functionality, while very good and useful for certain situations, is not script code and, as far as I can tell, is not intended to be.  If you need to write script code, you write script code and then you can call those routines within a keyword test if you need to.



I like the suggestion and perhaps SmartBear can do something on those lines, but I'm not sure how without doing a lot more expansion of KWT that would probably go counter to their selling point, that being a nice way for non-developer/non-scripting automaters to be able to create automated tests quickly and easily.