Possible Issues

If TestLeft cannot access the internals of the Visual C++ application under test, check whether the tested application is compiled with debug information and whether generation of runtime type information (RTTI) is enabled.

• To access public, protected and private properties and methods of your Visual C++ application from your tests, compile your application with debug information.
• To access public members of MFC classes, enable generation of runtime type information.

For a detailed description of how to configure your compiler, see Preparing Visual C++ Applications for Testing.

The delay occurs when TestLeft is reading debug information for the first time. The amount of time TestLeft spends on reading the debug information depends on the size of the debug information. Large applications have a lot of debug info, and reading it can significantly slow down the test run.

If you do not use protected and private methods and fields in your tests, compile your application without debug information to speed up the tests.

If TestLeft cannot access the internals of a Delphi or C++Builder application under test:

• Check whether the tested application is compiled with debug information.

  To access public, protected and private properties and methods of your application from tests, compile it with debug information:

  Preparing C++Builder Applications for Testing

  Preparing Delphi Applications for Testing

  If your application is compiled without debug information, TestLeft can access only published properties of the application.

• Make sure that the application is not compiled with a tool that may change the debug information format.

  TestLeft is incompatible with tools that change the debug information format. An example of such a tool is EurekaLog 7. We recommend that you disable EurekaLog when compiling an application that is aimed for automated testing with TestLeft.

• Check whether the tested object of the application is visible.

  The methods and properties provided by TestLeft can be applied to objects (specifically to VCL objects) which are currently visible. If your tested object is invisible in your application, you will not be able to call the properties and methods provided by TestLeft. As a workaround, you can –

  • Call the object’s native properties and methods instead.

  • Make sure the object is visible before callings its properties and methods provided by TestLeft. (You may need to simulate user actions over your application to make the object visible.)

TestLeft cannot get access to internal methods and properties of Java and JavaFX objects if the tested application was launched with the -verbose or -verbose:class command-line argument.

To resolve this issue, launch your application without these arguments.

If your Java application uses the Java Swing ComboBox, Java Swing List or Java Swing Tree control and the com.sun.java.swing.plaf.windows.WindowsLookAndFeel look and feel, launch your application with the swing.disablevistaanimation command-line parameter set to True, or specify the parameter in the application code. Otherwise, errors may occur when playing back your tests.

Here is an example of how you can specify this parameter:

When you are debugging a Java or a JavaFX application and TestLeft is running, an exception may occur in the application. When getting access to internal methods and fields, TestLeft may load classes to memory and the debugger may fail to find the appropriate class reference. To resolve this issue, do not debug your application when TestLeft is running, or do not run your application under a debugger.

During automated testing, when you start a Java application with JDK (or JRE) v. 1.6_18, the "Could not create the Java virtual machine." error message may be displayed. The problem is caused by insufficient memory allocation. 256 Mb of memory is sufficient for a Java application, but the Java 1.6_18 build apparently requires more memory.

Since TestLeft loads its helper modules to the address space of the tested application, the application’s memory consumption increases. So, loading additional modules to the application sometimes can lead to exceeding the 256 Mb bound.

To avoid this problem, it is recommended to update the Java console with the -Xmx512M parameter to increase memory allocation to 512 Mb.

This behavior is caused by the following reason: invoked subitems are not child items of the control’s context menu items to which they correspond (their Parent is an empty object).

For tests to run correctly, the tested application’s developer must associate the context menu items with the appropriate subitems in the application.

Due to the specifics of Qt applications, it is impossible to determine which menu is a control’s popup menu. Because of this, TestLeft considers the first child menu of a control as its popup menu. If the control has more than one child menu, TestLeft may recognize the popup menu incorrectly.

To avoid this, you can use one of the following solutions:

• Make sure the popup menu is the only child menu of the control

• Use the QtObject method to get to the popup menu. The method is available through the IObject interface in .NET, and the TestObject interface in Java. To learn how to call such methods, see Methods and Properties Common for All Test Objects.

  To avoid wrong recognition, specify the menu name in the windowsTitle property in your Qt application:

  C++

  C++

  pMenuObj->setWindowTitle("MyWndPopupMenuName");

  In this case, you can get the popup menu by using the following code:

  C#

  Visual Basic .NET

  Java

  C#

  using SmartBear.TestLeft;
  using SmartBear.TestLeft.TestObjects;
  using SmartBear.TestLeft.TestObjects.Qt;
  …
  
  public void Test()
  {
    IProcess qtTestApp = Driver.Find<IProcess>(new ProcessPattern()
    {
      ProcessName = "QtSample"
    });
  
    IMenu menu = qtTestApp.CallMethod<IQtMenu>("QtObject", "QMenu", "MyWndPopupMenuName").QtMenu;
    …
  
  }

  Visual Basic .NET

  Imports SmartBear.TestLeft
  Imports SmartBear.TestLeft.TestObjects
  Imports SmartBear.TestLeft.TestObjects.Qt
  …
  
  Public Sub Test()
    Dim qtSampleApp As IProcess = Driver.Find(Of IProcess)(New ProcessPattern() With {
            .ProcessName = "QtSample"
    })
  
    Dim menu As IMenu = qtSampleApp.CallMethod(Of IQtMenu)("QtObject", "QMenu", "MyWndPopupMenuName").QtMenu
    …
  
  End Sub

  Java

  import com.smartbear.testleft.*;
  import com.smartbear.testleft.testobjects.*;
  import com.smartbear.testleft.testobjects.qt.*;
  …
  
  public void Test() throws Exception{
  
    TestProcess qtSampleApp = driver.find(TestProcess.class, new ProcessPattern() {{
      ProcessName = "QtSample";
    }});
  
    Menu menu = qtSampleApp.callMethod(QtMenu.class, "QtObject", "QMenu", "MyWndPopupMenuName");
    …
  
  }