Keyword testing vs Scripting testing.

To answer your second question first, yes, you can use both on the same project.  Keyword tests can also call script tests internally and vice versa.  Keep in mind that Keyword Tests are UI constructed tests that are added to TestComplete to make it easier for "non-coder" people to create and modify tests.  



I'm working on a best practices document for my company right now.  As the following is not proprietary information, I can give you this:

Keyword tests are limited in their ability to do certain complicated tasks.  A best practice is to avoid keyword tests when: 1.      The task to be automated involves testing items that don’t have any related GUI (e.g., database stored procedures, Web Service API’s, etc.) 2.      The task to be automated involves manipulating the data or strings that will be used in data entry but does not itself involve data entry (e.g., formatting an SQL statement, formatting a date for input, concatenating strings, etc).  You can write separate Script code to perform the manipulations for use within a keyword test but the keyword test itself should not be used for doing the manipulation. 3.      The task involves data driven testing where only a select number of records from the data table are needed rather than the entire table. 4.      The task involves creating a function that will be used for providing data to other tests. 5.      The task involves using complex objects as parameters rather than simple strings or integers (e.g., operating on objects within the AUT where the object is passed in as a parameter) 6.      The task involves logic that changes dependant upon multiple variable values such as would be used in a JScript “switch” statement. 7.      The task requires complex error handling for determining multiple paths for execution.   Keyword tests are good candidates for tests when: 1.      The task involves UI manipulation for the purpose of executing a specifically defined task (e.g., logging in to an application, closing an application, navigating to pre determined pages, etc) 2.      The task involves a repetitive loop over a set of data for repeated entry into a web form 3.      The task has a low risk of dependency on data conditions for determining workflow. The task consists primarily of UI interaction with checkpoints with minimal manipulation of the data before the interaction

Note, please, that in the first list, this does not mean that keyword tests can't do those things.  It simply means that I've found, through experience, your code will be more efficient and easier to follow if you use script code in those circumstances rather than keyword tests.  I've done both, actually, and it does work.  However, where for keyword tests a task may take 10 distinct actions/operations, script code may be able to do it in half that much code (or even less).



Note, also, my signature below.  These are my opinions only and do not reflect SmartBear's policies.



Personally, I've grown to like using Keyword Tests for certain tasks as it does make my life a lot easier.  I can click and drag operations and actions around to re-organize logic in ways that would involve a lot of copy/paste stuff in code that is very easy to mess up.  I can drop in a quick piece of logic or a quick checkpoint into a keyword test rather than having to write a bunch of code.  And the wizard interface for adding operations is VERY nice to making sure that I don't miss crucial parameters, options, and so on in constructing certain actions.  However, there are times when I find that the UI interface for keyword tests and the way that actions have to be constructed get in the way of more elegant coding techniques and I jump to my personal default of "hand written" code.