Forum Discussion

rvg's avatar
rvg
Occasional Contributor
4 years ago

low-level mechanism of modifying the state of java controls

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

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    4 years ago

    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's avatar
      rvg
      Occasional Contributor
      4 years ago

      >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's avatar
        AlexKaras
        Champion Level 3
        4 years ago

        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's avatar
      rvg
      Occasional Contributor
      4 years ago

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