TestComplete IDE not recognizing common JavaScript
I have a request/question for SmartBear/Community. Take a look at the attached image and tell me if anyone knows a workaround for this issue. I'm using a very commonly used JavaScript design pattern. TestComplete IDE does not seem to be able to recognize it. It only seems to be able to read till <ScriptName>.<Obj>. It cannot seem to read anything inside the Obj, this is very annoying considering the fact that managing everything using plain functions and not encapsulating them inside an object can become greusome if at all anyone plans on making the code resuable (read function name clashes).
I was wondering if anyone has come across this issue or knows a better design pattern other than creating new functions and global variables without objects.
I was wondering if anyone has come across this issue or knows a better design pattern other than creating new functions and global variables without objects.
Hi Jerin, unfortunately you are correct, the Test Complete editor can only read till <ScriptName>.<Obj> and there is no way to configure it so it can.
In terms of patterns, I intially made the mistake of assuming the Test Complete JScript runtime was the same as a Web Browser, therefore I implemented a "Class" structure as I would have for a Browser application, e.g. namespaces and encapsulated Constructors and Modules.
As it turns out, the Test Complete run time is not like a Browser run time at all, from what I can work out, when a Script Unit is run, Test Complete seems to do the following:
1. Parses each Script Unit
2. Creates a singleton for each Script Unit
3. Each singleton then runs within its own sandbox, effectively making each Sript Unit a "blackbox" that can only interact via messaging, i.e. there is no overarching global object as you would find in a Browser
Point 3 can prove troublesome in that:
a. Any prototype augmentation (e.g. adding an indexOf method to Array (yes, the Test Complete JScript engine is that prehistoric)) only applies in the Script Unit it is defined in. In order to use an augmented object, a factory function must be provided by the defining Script Unit which other Script Units can call to get an instance of the augmented object.
b. Exception handling between Script Units sometimes works, depending on whether an Exception is raised in a Script Unit function or within a User object *sigh*.
I have attached a couple of Script Units that demonstrate this.
I recently gutted the entire Namespace structure and removed every Module bar one from our tests as it become a pain in the butt for others to develop with.
I still extensively use a similar user object pattern as yours, I just have to bite the bullet and rely on documentation and test developer ability instead of intellisense.
I now have the following basic patterns:
1. Any code I would normally encapsulate in a Closure based Module that would be considered a Static class in C# is now simply global within a Script Unit. The "blackbox" nature of the Test Complete run time provides enough differentiation between same named members in different Script Units, and as it is in house test code, the lack of privacy really isn't an issue. For the odd occasion where privacy is desired, I just define a simple Closure based Module with the private members and simple accessors that the public Script Unit functions can call.
2. Closure based Modules for a Singleton that represents an entity.
3. Instantiable Constructor based User Objects that represent test entities.
Hope this helps,
Phil
