8

I work with automated testing of a very large Delphi XE application using TestComplete 9. The application has a 180MB executable. The automation environment is Windows XP, 32 bit.

TestComplete is unable to access public, protected or private properties. Published properties may or may not be accessible - there doesn't seem to be any pattern to whether or not a given published property can be accessed. All methods are usually accessible, but may be unavailable, again without any observable pattern. The automation codebase has not changed.

Initially, I observed occasional instances where form information that should have been available to TestComplete wasn't present. The same automation could be rerun against the same executable and access the information without errors: the pattern of failure appeared to be random and was never solved.

Now, not only does TestComplete working with the large application fail to access properties and methods necessary for the automation to complete, when TestComplete attempts to access the information it will often cause the application to fail with no further information. This behavior can be reproduced with the application at will, but can't be built into a test application.

The application has been under more or less continuous development for about 25 years, and still includes some of the original DOS TurboPascal procedural code, so the internal workings of the application are very complex.

Can anyone point me to any resources or suggestions for getting the automation running again? At present there is maybe 3 hours (of 60) automated regression being performed due to the problems with accessing application internal information.

Improve this question
6
  • Did this just start happening when you upgraded to TC9?
    – Todd Bumbarger
    Commented Aug 16, 2012 at 14:23
  • And also do you need to include the file necessary to your application to expose its properties to TC?
    – Todd Bumbarger
    Commented Aug 16, 2012 at 15:39
  • 1
    Are you able to apply an older build of the application (Say from a month ago) to see if that works? If you can narrow down when it started, that would help determine if it was TC or your app. Any change in the environment? Hardware, OS?
    – Todd Bumbarger
    Commented Aug 20, 2012 at 17:14
  • 1
    The problem seems to be absolutely technical and I do not think that you will be able to get a proper resolution here. Contact SmartBear Technical Support to get assistance: support.smartbear.com/message/?prod=TestComplete
    – Dmitry Nikolaev
    Commented Aug 21, 2012 at 8:16
  • 3
    With a lot of work, and SmartBear technical support, we know what's happening now. We don't know why, but the debug info is being corrupted in some way.
    – Kate Paulk
    Commented Aug 21, 2012 at 22:41

1 Answer 1

Reset to default
6

I'm answering my own question here for everyone's reference.

With a lot of back and forth between SmartBear and Embarcadero the cause of the problem has been found:

  • In Delphi XE (and presumably later versions) there is a bug in the build process that corrupts debug information. This has been reported to Embarcadero and my workplace is working with them and SmartBear to find workarounds for the problem.

Workarounds are: - The build option to build with (I think) run-time packages appears to reduce the corruption of debug information but not eliminate it entirely. - With run-time packages, TestComplete needs to have the large-address-aware flag enabled or it will run out of memory.

We don't have a fix yet, but this much information could help anyone else who runs into this. Because this is a bug in Delphi XE, it has the potential to impact any automation tool that uses debug info.

Improve this answer
3
  • If this has any relationship to the problem back in BP7 a partial workaround is to turn off debug info wherever you can.
    – Loren Pechtel
    Commented Dec 17, 2017 at 16:26
  • @LorenPechtel - that does help, but not when it's not possible to access components without debug info. I no longer work at that place, so I don't know what the end solution way, but it was certainly troublesome bug. When I left, the team was rewriting the automation to handle as much as possible without debug info.
    – Kate Paulk
    Commented Dec 18, 2017 at 12:51
  • That's why I called it a partial solution. I would turn on the debug info in the code I wanted to look at, it would be turned off everywhere else.
    – Loren Pechtel
    Commented Dec 19, 2017 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.