Keyword vs Scripting in Test Complete 12

[micheleaz]

Hi all:

I searched in the forums and this discussion occurred years ago but I feel that things may have changed in the latest version. My question is this:

Scripts vs keyword tests-- which is better for a .Net VB application? I am currently working on building an automation infrastructure/library for a suite of applications written in Visual Basic with highly visual components. I do have scripting/programming experience in automation, but it seems if keyword tests-- you get more bang for the buck. I have figured out how to call various aspects of my application and do checkpoints via keyword tests. What is the advantage of recording a script test or writing one within the confines of test complete? I am not really seeing any benefit here. Also is it true that if you write a script from scratch you cannot get a visualizer component?

Thanks!

Michele

[Manfred_F]

Well, if keyword testing does Your Job for You, then use it! For Standard purposes, it will work great.

Scripting gives You by far more flexibility, if You Need this. I do.

"Scripting +" means creating Your own libraries, usig script extensions or the SDK.

[tristaanogre · Accepted solution]

Keyword testing does very well for creating tests where the folks doing the creation don't have a lot of actual coding experience or expertise.  You can easily create robust and well formed tests using keyword tests.  However, I've found that for some of the more complicated tasks (like the one I'm working on right now where I need to run a stored procedure on a SQL server and check the result on screen in the application), Scripting works better.  I'm sure I could figure out a way to build the ADODB objects, assign properties, etc., in a Keyword test but I've found that kind of work to be cumbersome where writing JavaScript or Python code would be more efficient and compact.

As for writing a script from scratch and getting visualizer... the same is for writing a keyword test from scratch without recording.  No visualizer is created necessarily at the time of writing it.  However, you can tell TestComplete to capture the visualizer images at playback to add them to your test case after the fact.

As for "more bang for your buck"... everything you can do in Keyword tests can be done in Script code... checkpoints, screenshots, loops, code logic... it's all, basically, the same.  The only difference is Keyword tests have the particular set of operations that need to be used to build the test where Scripting you can do a lot more in the way of creating custom code, routines, etc., and leverage all the features of your chosen scripting language.  For example, you can't create custom JavaScript objects and classes in keyword tests.  I use these for building my SQL queries, for running my framework, etc.  Not possible with keyword tests but certainly possible with script code.

As @Manfred_F said, use Keyword testing if it works for you.  If you don't need anything more, then by all means, use it.  But I've found that a good, well thought out blend of the two works pretty well, too.  Code libraries of script routines that can be used within the keyword tests, Script Extensions to build my own runtime objects... I've even started looking into building my own plugin using the SDK (although, this will be a new exploration for me).  I honestly, don't think Keyword testing replaces Scripting at all... but it certainly is good for building tests quickly that can then be supplemented by the aforementioned tools.

[NisHera]

As the others says if Keyword works for you great..! it quick and easy.

initially I started with keyword testing and found that scripting is more flexible and suitable for me.

Since had not much coding experience scripting was challenging but enjoyed learning.

now I almost forgotten KDT and entirely on scripting. 

Hence I presume it's kind of personal preference, though keyword testing targeted for less coding experienced people. 

[zdanov]

 Hi NisHera, 

Could you please briefly share your experience when transitioning from key-word to scripting with TC? Like yourself at the beginning, I am also all about key-word approach, but I'm curious to know how did you go about transitioning to scripting and learning to script with TC?

Any pointers would be great! 🙂

Thanks!
Serge.

[tristaanogre]

Well, first, learn the language... scripting is a bit different than Keyword testing because it is an actual code language that you need to be able to write.  There are tutorials online for learning any number of the scripting code languages.  But definitely, start there... if you've never written code before, then you REALLY need to start there.

From there, you can take anykeyword test and convert it to script by right clicking on it and select the conversion option.  That will then give you a comparison of something you know (keyword test) to something new (script code).

[zdanov]

Hi Robert, 

Thank you for your reply. I am not a complete stranger to code, it's just that the last time I wrote a program was in college, about 17-18 yrs ago, not counting SQL queries I frequently use today, of course. 🙂

Our apps use C# predominantly (windows and web), which I can somewhat read and understand, but writing it from scratch is a whole different story 🙂

Thanks!!

Serge.

[AlexKaras]

Hi Serge,

Likewise mentioned by Robert, you may also consider script recording. This will give you all the infrastructure (function and variable declarations) and initial code. Then you can analyze recorded code and try to run it. If the run succeeds then it's fine. If not then you'll have a challenge to understand why it is not working and correct the code. Then you may proceed with things like data parameterization (use (semi-)dynamic data instead of recorded hardcoded ones); moving common parts of code into support functions; stabilization improvements (e.g. implement waiters that wait until this or that UI element appears on the screen or is populated with data from external source).

The above is a kind of 'incremental way' when you are not forced to create the whole code from scratch, but already have something that (almost) works, so you can improve and enhance it according to your needs.