CraigB
5 years agoContributor
Refresh files
Hi
I can't find the command to refresh files. How do I force TestComplete to refresh all files so that changes are reflected in the script files it's using to run tests if I change something w...
No.
When you click "run" in TestComplete to run a project, it basically does a Runtime compile of all the script files. So, while you can change files while the project is executing, it will not take effect until the next execution. This is why there are certain options that you can change during a run and certain ones you can't.
The suggestion for OnLogError is to allow you to execute special code when an error is written to the log. It doesn't allow you to CHANGE the scripts while running, just that you can set up to run code on an error that will do certain tasks at that error. You still can't change code and have that changed code execute. Sorry, man.
The problem is that the changes don't even take effect on the next run because unless I hack my way around it, TestComplete doesn't refresh the changed files if they were changed while it was running tests.
Generally... don't change files while the tests are running. I think TC flushes back to disk anything that was used for running.
If you need to alter files while the test is running, I would suggest you open a copy of TC on another machine, make your changes, check them into your source control, and then redownload to the execution machine.
TC doesn't overwrite files I change while it's running.
That proposed solution is even worse than what I'm currently having to do. It's bad enough that I have to make unnecessary changes to the files so that the timestamp is changed to get TC to refresh the changed files. Making unnecessary source repository commits on a second machine (for which I'd have to buy a second TC license) and then pulling those to the primary machine... The less said about how ridiculous that is, the better.
Sorry Craig that you feel that tristaanogre 's help is ridiculous, he is just trying to help you.
The fact that you bought a TestComplete license to end up using other editors to work on your TestComplete files, is the ridiculous part. You only need a TestExecute license for that which is 1/10 of the price.
What tristaanogre and I (and other community members) are trying to do on this form is help everyone voluntarily with our knowledge and experience with the product.
You can always fill a support ticket and get answers directly from the TestComplete Support Team if you prefer.
The way you are using TestComplete is unorthodox and not the best way to use TestComplete.
I believe tristaanogre was trying to help you realize that and save you time.
Cheers
Lino
It appears your labouring under a couple of misapprehensions. One is that I have time to waste waiting for tests to complete before I make script changes. I can't understand why anyone would be willing to waste time like that. If there's a problem with a script, or even if the latest change works and so now I'm going to go on to adding the next steps, why would I wait rather than just making the changes? The second is that you seem to think I actually use TC as a place to edit anything other than things that are TC-specific. I value my time and sanity way too much to consider editing scripts in TC. TC is a place to run test scripts. It's certainly not a place to do any sort of code editing.
Either way... TestComplete cannot use new script code while the automation is running. It's not a dynamic project like a web page that updating script and hitting "refresh" will cause new code to be used right away. Again, the best analogy I have to explain is that clicking "Run" on TestComplete essentially "compiles" what is to be run at that moment and loads it into memory. Anything that is executed is done off that in-memory copy. So, even if you change the script at that time, TestComplete cannot use it until the NEXT execution. So it really doesn't matter what tool you use to edit the script, TestComplete must wait until the next execution to use the new code. This is the way it has been since I started using the tool in version 1.52. It's a fundamental architecture.
As to "refreshing" the code changes AFTER the execution is run... My suggestion still stands, whether or not it meets what you're expecting. New script changes need to be brought into the project through some other means. I'm guessing that when the automation completes, the old code is still present on screen and the new code is not there. If you close the project (and don't save changes) and then re-open, your new code SHOULD be present at that point and available for the next execution.
As for waiting for the execution to complete before trying out new code... that's why most users here separate their development environments from their execution environments. LinoTadros 's suggestion of using TestExecute to actually run the project is part of that. You have an environment (VM, etc) that has TestExecute on it and on which you have a client for your source control tool. You pull down the latest source and then execute it with TestExecute (no IDE or anything required, just command line). CI tools like Jenkins are great for this.
Then, in the meantime, on whatever environment you choose, using whatever code editor you choose, you can continue to develop your automation. For myself, when I'm developing, I NEVER execute a full project (ours takes upwards to 14 hours to run) in my development environment. I create harnesses, etc., to test new code before I put it out for general test execution. That saves me time for my debugging process and makes for much more stable code for general execution.
We are happy to continue to help you figure out a solution that will work for you. But please keep in mind the limitation that I mention at the top: That new code will not execute until the current test is done. There are any NUMBER of techniques, processes, procedures that you can use to work with code while a test is running, but you cannot get around that limitation.