Home » Archived » Jubula » Web Browser AUT Problem - Input Text and Replace Text Actions(The actions ub_cti_inputText and ub_cti_replaceText fail on some web sites.)
| Web Browser AUT Problem - Input Text and Replace Text Actions [message #1725510] |
Fri, 04 March 2016 04:35  |
 Drew Snader
Messages: 7
Registered: February 2016 |
Junior Member |
|
|
Jubula Team, welcome to your new digs! Where are the move-in party photos?
When I use the concrete toolkit actions ub_cti_inputText and ub_cti_replaceText in tests on some web sites, those actions fail with the Action Error "Operation not supported by the selected toolkit".
My environment is as follows:
OS: Windows 7 SP1 x64
Java: JRE version 1.8.0_73
Jubula: x86 version 8.2.0.21
AUT: Chrome x86 version 48.0
Project Toolkit: HTML
See the following attached image files for project/AUT configuration info:
Jubula_WebBrowserTestDemo_ProjectConfiguration.png
Jubula_WebBrowserTestDemo_AUTConfiguration_ChromeAirtable.png
Jubula_WebBrowserTestDemo_AUTConfiguration_ChromeGoogle.png
For example, the inputText and replaceText actions work correctly when they are used in tests on the Google web site (ww.google.com) to enter text in the home page search text input field. (See test results in the attached Jubula_WebBrowserAUT_GoogleWebSiteTestResults.png image file.) The ub_cti_replaceText action also works correctly (no surprise) in the Jubula Samples Simple Adder HTML tests.
However, if I perform a similar test, to enter text in the Sign In page Email text input field on the the Airtable web site (airtable.com), the test fails for either of the inputText or replaceText test cases. (See test results in the attached Jubula_WebBrowserAUT_AirtableWebSiteTestResults.png image file.)
Both web sites use HTML 5 (<!DOCTYPE html>). I have examined the page source on the Google and Airtable web sites, but cannot see any significant differences between the input tags for the components used in the tests.
At the time of the test failure, there is one entry in the rc_html.log. It is:
2016-03-03 11:15:57.515 [Connection.ReaderThread:Socket[addr=/10.0.2.15,port=49344,localport=49905]] ERROR o.e.j.r.c.commands.CapTestCommand - implementation class method not found
java.lang.NoSuchMethodException: No such accessible method: rcReplaceText() on object: com.bredexsw.jubula.rc.html.web.implclasses.forms.label.LabelImplClass
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:278) ~[commons-beanutils-core-1.8.01703674007884132775.jar:1.8.0]
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:225) ~[commons-beanutils-core-1.8.01703674007884132775.jar:1.8.0]
at org.eclipse.jubula.rc.common.commands.MethodInvoker.invoke(MethodInvoker.java:64) ~[org.eclipse.jubula.rc.common_4.0.0.201510211215.jar:na]
at org.eclipse.jubula.rc.common.commands.CapTestCommand.execute(CapTestCommand.java:228) ~[org.eclipse.jubula.rc.common_4.0.0.201510211215.jar:na]
at org.eclipse.jubula.communication.internal.Communicator$ConnectionListener.received(Communicator.java:918) [org.eclipse.jubula.communication_4.0.0.201510211215.jar:na]
at org.eclipse.jubula.communication.internal.connection.Connection.fireMessageReceived(Connection.java:402) [org.eclipse.jubula.communication_4.0.0.201510211215.jar:na]
at org.eclipse.jubula.communication.internal.connection.Connection.access$2(Connection.java:391) [org.eclipse.jubula.communication_4.0.0.201510211215.jar:na]
at org.eclipse.jubula.communication.internal.connection.Connection$ReaderThread.run(Connection.java:454) [org.eclipse.jubula.communication_4.0.0.201510211215.jar:na]
A colleague of mine has confirmed the problematic behavior in independently coded Jubula tests using his similar test environment.
Could you try to replicate the problem and provide insight as to why the inputText and replaceText actions would behave differently on different web sites?
|
|
|
| Re: Web Browser AUT Problem - Input Text and Replace Text Actions [message #1726290 is a reply to message #1725510] |
Fri, 11 March 2016 06:32  |
Drew Snader
Messages: 7
Registered: February 2016 |
Junior Member |
|
|
I think I may have discovered the root cause of the error I reported.
On closer inspection of the exception stack trace in my original post (OP), I noticed that the object data type listed in the error message is LabelImplClass. The exception that is thrown (NoSuchMethodException) makes sense, because the LabelImplClass would obviously not have a "rcReplaceText" method, since that class is for label components. The object data type that should be passed to the MethodUtils.invokeMethod() method (in the stack trace) should actually be a TextImplClass. So Jubula is trying to handle the wrong kind of component.
I also took a look at the HTML input tags for each of the web pages I mentioned in my OP. They are shown below.
Simple Adder Web Page
<input type="text" name="value1" id="value1" align="right" class="field" onkeypress="return createResetBtn('resetTag')">
Google Web Page
<input class="gsfi" id="lst-ib" maxlength="2048" name="q" autocomplete="off" title="Search" type="text" value="" aria-label="Search" aria-haspopup="false" role="combobox" aria-autocomplete="both" dir="ltr" spellcheck="false" style="border: none; padding: 0px; margin: 0px; height: auto; width: 100%; position: absolute; z-index: 6; left: 0px; outline: none; background: url("data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw%3D%3D") transparent;">
AirTable Web Page
<input type="email" class="email" name="email" placeholder="Email" value="" autofocus="">
I can see two differences between the tags that might cause the problem I observed.
First, on the Simple Adder and Google web pages, the type attribute for the input tags is set to "text", whereas the the type attribute for the AirTable input tag is set to "email". The Jubula application's ComponentConfiguration.xml file contains specifications for a html.forms.input.Text toolkit component and a html.forms.input.Password toolkit component, but there is no specification for a html.forms.input.Email toolkit component. Could that be the reason that Jubula does not recognize the AirTable Email field as an input tag and is treating it as a label?
Second, the AirTable input tag has an HTML5 placeholder attribute, which causes the text input field to display a short text message inside the input field to give the user a hint as to what to enter in the field. The Simple Adder and Google web page input tags do not use that attribute. Could the "placeholder" text displayed in the AirTable input field be confusing Jubula into thinking that it is dealing with a label instead of an input component?
To test the first hypothesis (that type="email" in the AirTable web page's input tag may have caused the problem), I modified my AirTable test suite and ran another test.
If you look at the image file Jubula_WebBrowserAUT_AirtableWebSiteTestResults.png in my OP, you will notice that the test results screen image shows that the AirTable "Sign In" page has two input fields: one for an email address (type="email") and, below it, one for a password (type="password"). In my original AirTable test suite, I naturally tried to enter the email address first, since that is the first input field on the page. That is where my test failed. To modify the test suite, I set as inactive the test case step that enters an email address in the first input field, so that the test now only tries to enter text into the Password input field.
When I ran the test, it successfully entered a text string in the Password input field. So, only the Email input field (whose input tag uses the type="email" attribute) causes the error.
I conclude that, to correct the problem, the Jubula ComponentConfiguration.xml file needs a new entry added for a html.forms.input.Email toolkit component and the TextImplCass tester class will need to be updated to implement that new specification.
As far as my second hypothesis goes (that the "placeholder" attribute may have caused the problem), I don't have an easy way to test that and the results of the hypothesis #1 test are pretty compelling to me, so I will assume that hypothesis #2 is not valid for now.
So my questions are (You thought I would never get to the questions, right?): Could you please determine if my conclusion is correct and let me know? If it is correct, is there anything more that I need to do, like submitting a bug fix request, to get the ball rolling on fixing the problem?
[Updated on: Fri, 11 March 2016 06:35] Report message to a moderator |
|
| | |
Goto Forum:
Current Time: Thu Apr 25 17:59:07 GMT 2024
Powered by FUDForum. Page generated in 5.03505 seconds |
] 
Search
Help
Register
Login
Home
, it is probably a wise choice. 