hlalumiere
Regular Contributor
Joined 13 years ago
User Profile
User Widgets
Contributions
Another attempt at bettering my TestComplete COM experience, another failure...
So we supposedly can, through "connected applications", use TestComplete runtime objects like Sys, Log, Project, etc... The only issue is that no autocomplete is available, no documentation is available, only late binding is supported, etc etc etc... Can no one see how this is a problem? It basically makes connected applications a big pile of useless stinking static code. It removes any advantage I would have potentially got from using a managed language to write my tests. So I played around. Simplest way I figured I could try to fix the problem is by looking at the internal interfaces exported through Interop.TestComplete.dll. The closest match I could find for the Sys object is the ItcSysNode interface, but it is incomplete (meaning the Sys object evidently also implements other interfaces, I just have no idea which ones...). In addition, in the multitudes of not-so-useful interfaces referenced in Interop.TestComplete.dll, not one of them seems to correspond to the Log object (or any other runtime scripting object). So obviously these interfaces are either inexistant or not exported. No worries, I have other tools... Next, let's try reflection! TypeName function in VBScript reports Sys object is of type IDispatch. "Great!", I think to myself, "I can use reflection to reconstruct the COM type and instanciate it in .NET!". Standard reflection, however would not work through a late-bound COM object. So I reuse this little gem that has always worked for me in the past: http://www.codeproject.com/Articles/523417/Reflection-with-IDispatch-based-COM-objects The only problem is that the GetTypeInfo method of the IDispatch interface is not implemented in the TestComplete object! So TestComplete objects advertise IDispatch implementation, but it is an incomplete implementation... That's just great... Can a senior dev working on TestComplete possibly take heed of these comments and do something about it? Would it really be so hard to add a couple of interfaces to your already humongous pile to cover the runtime scripting objects? Or maybe implement IDispatch properly? Or even give me a list or ProgIDs or CLSIDs for the runtime scripting objects? The documentation around "connected" applications stinks. I don't understand how you expect people to develop competitive, modern "connected" applications without you supplying comprehensive documentation on the interfaces, types and programming model for your API. I apologize if this sounds harsh, but man everytime I try something with this clumsy API I lose massive amounts of time just trying to guess things that should be clearly documented.1.1KViews0likes1CommentRe: Discrepencies around COM Object registration
You do not need to worry about COM registration at all to be honest, unless your installation was damaged. To get the reference to TestComplete or TestExecute, reference the .exe. Visual studio will generate an Interop DLL when you build. Copy that DLL to the output, and then reference it instead of the exe from your app. Now you can develop your app on any machine no matter if it has TestComplete installed or not. When you actually instanciate check for an exception when creating the TestComplete.Application object. You can trap if something is wrong at runtime. In VB you could also use late binding to abstract it all away. But C# doesn't support late binding pre-4.0. In 4.0+ you can use late binding with the poorly-named "dynamic" keyword. (I say poorly named because both c# and vb are static languages, there is no dynamic typing...)2.1KViews2likes0CommentsRe: ETS, VMWare and TestExecute
Access to the remote VMWare console requires rights to access the VSphere client for the server but it does not necessarily require admin access. I do not believe it will cause any issues, since a VMWare remote console is essentially the same thing as a physical screen connected to the virtual machine. As for the Network Suite I do not know since I do not use it.2.3KViews1like0CommentsRe: ETS, VMWare and TestExecute
Couple of small innaccuracies in the answer above: 2. A connection, be it RDP or other remote connection protocol needs to be kept open to the machine. Otherwise Windows will not render a desktop and you cannot run GUI tests. This is common to all GUI testing in Windows and not just TC. A popular method to do this is to run a tool like VNC server (or equivalent) on your testing machine. Configure the software to keep the connection open after you disconnect. This tricks the testing machine into thinking a monitor is attached. Windows will always render to a framebuffer, no matter what. Whether that famebuffer is connected or nor to a screen is another matter completely. You do NOT need to keep a connection open all day long to the machine. The hypervisor (be it VMWare or Hyper-V or whatever else) provides a virtual monitor anyways. The problem with RDP is specific to RDP. When you establish a connection to a RDP server you are establishing a connection to a new or existing session. Locally your session is called the console session. The console session is normally only ever tied to the physical (or virtual) screen. When you connect remotely, a new session is created for you to work in. The problem is that when you log off, by default Terminal Services disconnects the remote session and connects back to the console session and then locks it. So, any other remote access service that runs as a service and does not lock the session on logoff will work fine, with or without you ever connecting to it. If you are lucky enough to be running an enterprise version of VMware you can probably just connect through a console session to the machine using the VMware tools and no other software is required. As noted, VMWare offers its own tokenized remote access protocol, and it is recommended you use it instead of RDP or anything else, as it works directly through the VMWare hardware abstraction and introduces no incompatibility whatsoever. However that is not only available with an enterprise license. Most people forget about the free ESXi! This is what I would recommend getting here, it's 100% free, the same solution as enteprise users, and the only real limitation of the free license is no remote management API (as in VMWare VCenter to administrate multiple servers). Each VM is still reachable with the remote console, and you can still use local APIs (the Guest API for example to control VM state from within the VM...).2.7KViews3likes0CommentsRe: How to use the Testcomplete log object
It's in VB.NET, and no I cannot share it because it's highly specific to our setup. Keep in mind you could do the whole thing in any language you like, it could even be just a web app. The important part is to gather the data in a database. The rest is just visualization.2KViews0likes0CommentsRe: How to use the Testcomplete log object
It's an application I wrote internally to manage our bank of 45 test machines. Essentially I just export the log to HTML after the test, and insert the tests results in the database along with the path to the exported logs. The application updates itself as the data adds up to the database.2KViews0likes0CommentsRe: How to use the Testcomplete log object
I did exactly that, but through a dashboard application in our case. This is what it looks like: The data in there is derived from our testlogs which are entered in a SQL database by our automated test controlled (also written in-house). In your case you could fill the table by writing to the databse directly from your scripts, as said above through events. This is what our TestLog table looks like:2KViews1like0Comments