We have just upgraded to TestComplete 6. The command line syntax for running this version is the same as previous versions so I went ahead and changed my setting in FinalBuilder to point to the correct path for the new version to see if everything would still work properly.
When I attempt to run my tests they start to run, but they fail with an "Execution timed out. Unknown result code : 1001" message every time.
If I instead take the command line that shows was run in the log and add quotes around the program path (Program Files has that space that messes things up otherwise) and then create an execute program type action, my test runs without any problems.
I'm fine with the workaround, but wanted to let you know about it in case you want to address it.
The program path shouldn't need to be quoted in either the Execute Program Action or the built-in action. It's actually passed directly to a Windows API function.
Were there any other quoting problems, possibly with the project file path?
We'll update the action to officially support TestComplete 6 some time in the near future.
Sorry it’s taken us a while to get back to you on this. TestComplete 6 seems to work fine with the existing TestComplete 4/5 action, just update the path to point to TestComplete 6. We’ll update the action to reflect this.
If you’re still getting Error 1001 when running the tests, please let us know and we’ll look into it some more.
No problem with the delayed reply. Things actually started working at some point for me. However, I'm getting some very strange behavior now and it appears that it is somehow related to FinalBuilder, though I can't say that for certain. Let me describe what is happening to you.
I have a test suite that is checked in to StarTeam and checked out to the local D drive through my FinalBuilder action. When I run the test through FB, it fails with a message
Execution timed out. Unknown result code : 1001 (See the TestComplete log for details.) The following error data was logged by TestComplete: 10/30/2007 08:23:38:837 Tried to open the YES/NO dialog. Message: The project suite 'W:\ADM\WESS\AutomatedTests\WESS\WESS.pjs' is located on a network drive. Do you want to work with it in networked mode?. The default value: YES.
However, as I stated above, the test doesn't even reference anything on the network drive. Strange. Even stranger is that if I take the command line that FB says that it runs and execute it in a command window manually, the test works fine with no error messages.
Do you have any thoughts on what might be going on here?
To make this even stranger, I noticed that the date and time on the error message is from last October, but this is on a build I just ran right now. . .
In case this helps, once i have run TC through FB, the log file directory appears to be missing some of the important files that allow me to actually open and look at the logs. . .
I see. Do you have the "Silent Mode" option turned on in the action (or on the command line)? I'm not sure why TestComplete would be hanging with a prompt under this scenario, anyhow (let alone the "network drive" thing in the first place.)
Is there anything special at all about drive W:, or is it just a normal hard disk partition?
Have you brought this up with AutomatedQA tech support? Are they able to assist you?
I'm not sure what else we can do from the FinalBuilder side to make this work.
Your not alone Phyllis, I have the same problem with Finalbuilder 6 and testcomplete 5.
I spoke with Automated QA, and they told me its a problem with finalbuilder. I do run in a silent mode, In the logging you can see it will log the following action :
We have actually been successful now in running our tests via Final Builder. Sorry for not updating my posts here.
It ends up that the problem had something to do with the log files that TestComplete created that the project thought should be there. Because the tests are written on a different machine than the build machine, these particular log files didn’t exist on the build machine and therefore TestComplete didn’t know what to do with them.
Our test writer deleted the logs from the project and re-checked in the project source code and the problem went away.
As a note, we did switch to running TestExecute for our build machine because the test results are easier to deal with, and we really don’t need the full-blown test suite just for running builds. . .