Does TestComplete Truly run Headless (TestExecute as well)?
So we have one (1) TestComplete License, we have the TestExecute which comes with it.
There are Three machines involved in this scenario, but Only 1 Requires TestComplete
(named myDesktop to develop tests), and 1 (named myVM, a virtual machine) requires
TestExecute to run tests. The third Machine (named myAppMachine) houses the web
software I am testing.
Here's what works so far:
1) I can develop GUI tests and scripts in Testcomplete from myDesktop
*I can run them from myDesktop against an app on myAppMachine (Yay it works)
2) I can install TestExecute on myVM, and drop my tests/projectsuite there and
invoke TestExecute against them. Remember these tests are testing what is on
myAppMachine.
*I can log onto this VM, and successfully run my tests with TestExecute (Yay again)
3) I need to NOT Log into my VM to make this happen. I need to invoke a .bat file on
the VM from another system (or ps exec or whatever) and launch these tests
"headless" meaning NO HUMAN HAND clicks go, or types in "EXECUTE", or SEES
ANY GUI at any time. And yes of course some of these tests are GUI tests (Most in
fact). That's the point of trying this tool.
(Screech, Halt, Stop) <- I want this to say "Yay". Please tell me if this is possible.
Please do tell me if it's impossible so I stop reading about it and spinning my wheels
for no good reason. That is:
If you know I cannot launch a set of TestComplete Tests at the Completion of a build,
AUTOMATICALLY, on a remote machine, please tell me.
If you know I can indeed do this please tell me that instead and I will continue to try
and build a Test.proj file to launch a remote command to the VM to execute a .bat file
with a TestExecute invokation in there to run the tests.
4) I have read all your stuff at "Remote Tests via Remote Desktop", and "Running
Tests in Minimized Remote Desktop Windows", etc. I have made the Registry entry
for "RemoteDeskto_Suppressed_When_Mimized", etc. and cannot seem to find a
"Headless" answer. Here is what I mean by Headless":
After my tests (yes GUI tests) are written, dry run, put in place, and connected to a
script for launching I do not have to touch it to start it, or ever see the GUI. I just
want to see the results in my email (which I already "Packed" and emailed
successfully in a little script). My Build completion (Test.proj) will ultimately launch
them, but right now I cannot get them to run "Headless". Logging in and starting the
tests is not an option for me here so please be forthcoming because I LIKE YOUR
TOOL and I still want to believe it can do this.
If we can get this to work, I can develop a suite of tests. If it works (and continues
to work) we will renew our license next summer (and most likely upgrade it), otherwise
this tool will not serve us. For now I am the sole "Beta" person involved with this. I
write C#/Selenium tests and they run just fine headless (against the same app I am
trying to test headless with your tool). You can use a phantomjs driver (htmlunit driver if you are using Java) and these GUI tests run headless just fine.
BUT I WANT YOURS TO WORK FOR US. You know why? Two Reasons:
1) I am Stubborn and don't give up & more importantly:
2) If we get other "Testers" to use this next year, if we upgrade our license, your I
interface would be nice for them (not being developers). I can do the scripts and
other dev stuff for them). MY C# and Selenium works, but other testers are not
developers so I would have to be the sole developer of ALL the automated tests
for the rest of my life :(
Thanks, Chris
- Running a very similar setup to you - I had tests run automatically, and headlessly, on a VM as part of a build process.
The entire thing was kicked off by TeamCity (the build engine in use for the project). I simply gave them a BAT file to start TestExecute and it did the rest. Project was stored in version control. Application was web based. So run in a browser on a VM with part of the site hosted on a test VM elsewhere.
Entire run happened headlessly (as you mention, this is down to the setup of the VM). TeamCity would pull down the most recent version of the project from Source Control (GIT), dump it onto the VM with TestExecute installed and then start TestExecute using the BAT file I supplied. High level results were also captured by TeamCity and included in the results of the build. Low level results (which were linked to in the TeamCity output) were stored elsewhere on a network drive.
If I wanted to look in on the run (not often as it was overnight) I used VNC to view the remote VM. Using Remote Desktop to connect would cause the run to fail when you closed the remote connection.
So yes, it can be done. I'm not sure about how TeamCity was set up exactly as our build engineer did that part. I just supplied him with all the parts to make it work.