Forum Discussion
Here's my other thinking on this:
It may be that we're doing EVERYTHING right in mapping, delays, etc... but the simple fact is that there are more than one msiexec processes running when you run your tests. So, when it gets to that point, the mapping may be pointing to the msiexec process that is not the one with the UI displayed and so the object is coming up not found.
There have been multiple threads here on the forums of people who are trying to automate, through TestComplete, the use of the installer to install their application and, IIRC, this has been a standard problem they've experienced.
This may be one of those situations where doing an automated test may be more trouble than actually worth. However, one more suggestion... in your mapping for the process, have you tried adding "Required Children"? IIRC, only one msiexec process has the child objects of the UI. If you edit the process to indicate that it has certain required children, that MIGHT help out.
Hey tristaanogre,
I've tried your suggestion, but it doesn't seem to help. Overall it just feels so random if a test passes or fails.
It is also not just limited to the installer I'm trying to test, but also the software itself, that is installed with the installer.
I also unchecked the "Extended find" box: no effect.
Is there any cache TestComplete is creating in the background which I could delete, maybe that has some impact? Or does the "Store Object" function does has an impact on my tests?
Updating TestComplete to the newest version (12.60)?
It is really frustrating...
Anyway, thanks so far!
Fred
- tristaanogre7 years agoEsteemed Contributor
Something that would help us troubleshoot with you are screenshots of the Object Browser showing the state of the system at the point of failure, including all relevant properties and their values. Likewise, a screenshot showing your NameMapping of the components that are failing in context with their hierarchy and all properties used in the mapping. Additionally, when it fails, the error will usually give, on the Additional Info panel of the log, more details as to what exactly is causing the failure, specifically which "object" is not existing. It might not be the object we think it is.