low-level mechanism of modifying the state of java controls

[rvg]

While running a test for  java application we get the unexpected exception at some point. The line of code in TestComplete script which generates the exception is like this:

win.LicenseCustomerCode.wText := some_code;

In the application's Thread Dump an alien thread is present that was created very likely on behalf of TestComplete. The call stack of that thread is as follows:

"Thread-38129" prio=5 tid=950b RUNNABLE [3b88f3d9]
        at java.lang.Thread.dumpThreads(Native Method)
        at java.lang.Thread.getAllStackTraces(Unknown Source)
        at com.sterra.vdb.cache.VdbBase.check_vdb_readable(VdbBase.java:69)
        at com.sterra.vdb.cache.VdbTypes$VdbVpnProductImpl.name(VdbTypes.java:5380)
       .....
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.automatedqa.testcomplete014_007.JavaUtils.Method_invoke(JavaUtils.java:27)

As the developers say, the failure occurred because this thread tried to get access to a resource that is not allowed for threads other than main GUI thread.

To get the understanding of what is happening, we'd like to know:

1. Why the new thread should be created in the context of the application process under the test?

2. Would the TestComplete lost it's functionality if this thread was not created?

3. What kind of code is executed by this thread?  In the call stack this code is named as com.automatedqa.testcomplete014_007.JavaUtils.Method_invoke(JavaUtils.java:27) 

4. If this code is for changing the contents of the window's text field, why the function is called that accesses the inner resource: com.sterra.vdb.cache.VdbTypes$VdbVpnProductImpl.name(VdbTypes.java:5380) ?

5. Are there some specific rules or limitations for developers writing the java applications to guarantee  such failures do not occur during the tests?

Thanks for you help

[Marsha_R · Accepted solution]

That's a question that should be directed to Support.  Here's the link:

https://support.smartbear.com/testcomplete/message

[AlexKaras · Accepted solution]

Hi,

> win.LicenseCustomerCode.wText := some_code;

If LicenseCustomerCode is an editable control, you may try something like this:

win.LicenseCustomerCode.Keys(some_code);

Does it help?

[rvg]

Thank you, we have done it and are waiting for reply now

[rvg]

>If LicenseCustomerCode is an editable control, you may try something like this:

>win.LicenseCustomerCode.Keys(some_code);

>Does it help?

Yes, thank you!

But the problem is more complex as it seems to me. Not all controls being changed by the test have the 'Keys' method. It seems that there is some kind of inconsistency between the application behaviour and the logic of TestComplete while it uses a new thread to change the application controls.

As it is known from the papers for java writers, the multithreaded gui should use the SwingUtilities.invokeLater method when changing the state of a control by the thread other than the GUI thread. We don't see the call of this method in the call stack of TestComplete thread. From the other side, we see the call of the Listener in the context of this thread. All this is not clear and produces many questions

[AlexKaras]

Hi,

> Yes, thank you!

Great, thank you for the confirmation.

> Not all controls being changed by the test have the 'Keys' method.

I think that it is better to clarify this with Support using specific control(s) as an example as been suggested by Marsha.

As for me, wText property may or may not be modifiable. This can be checked in the Object Browser. Direct modification of the wText property sounds like the call to the .SetText() method (which you may also try, BTW) that directly assigns a value to the control, while some controls may be not designed for such scenario. So, if some control does not provide the .Keys() method, for me it looks like it cannot be modified by the human user and thus requires some special attention from the test writer. (Or not be modified from test code at all. Just because human user cannot do this.)

But the above are just generic thoughts which, as I already wrote, I think better to clarify with Support.

[rvg]

Hi,

my thanks again for proposed simple solution. I realized better that it is useful after I had read the documentation, Simulating Keystrokes | TestComplete Documentation (smartbear.com):

"Note that the SetText action changes the object text programmatically, so, it may take less time to execute. The Keys, KeyDown and KeyUp methods, in their turn, simulate actual key presses in the object, taking into account the Key pressing delay project setting. However, the key pressing methods also ensure that the appropriate keyboard events are raised in the tested application and the associated event handlers, if any, are executed. Therefore, these methods are preferable to SetText in certain cases."

As the result, we have decided to replace the usage of .wText := ... and .setText(...) by the calls of Keys(...) method everywhere it is allowed by the control. The remaining cases are those where the controls have a derived java class that does not support the Keys() method and so it is required to call .setText(). For these cases the initial issue is actual as the calls may be  executed in the context of automation thread and lead to possible failure. We sent the request to support and now are waiting for the results of analysis.

[AlexKaras]

Hi,

> controls have a derived java class that does not support the Keys() method

Consider Project Properties | Object Mapping settings to add derived class to relevant group and check if it make it possible to use .Keys() method with such controls.