This section provides information and instructions on a few features that are known to be difficult to use or need modification to work.
Replaying interactions in the LoginForm
component is somewhat
tricky due to the fact that the identifier of the iframe
element
that is used changes each time the application is restarted. The use of an iframe
element means that recordings have to select the target frame before fields can be
correctly identified.
Selecting the correct frame in the recorder can be done by modifying the
target
of the recorded selectFrame command. One
way to identify the correct frame is by specifying its 0 based index:
index=2
Another way is to specify an XPath selector for the iframe
. In
this case it helps if you can specify a debug ID for the LoginForm
component. In the example below, the LoginForm
's debug ID is "login".
xpath=//id("login")//iframe
Selecting the correct frame in JUnit code is done like in the following example.
getDriver().switchTo().frame(2);
Or
WebElement frame = getDriver().findElement(By.xpath("//id('login')//iframe")); getDriver().switchTo().frame(frame);
The assertTextNotPresent
and assertTextNotPresent
methods in TestBench Recorder are problematic in that they do not respect CSS rules that hide
elements (e.g. display: none;
). This means that you might have trouble
confirming that text is or is not present.
This will be fixed in a future release, but until then a better, albeit more complex, strategy
for testing whether a string is present on screen is to use the
assertElementPresent
method with an XPath selector as follows:
xpath=//div[contains(@style, "display: none")]//div[contains(text(),"HIDDEN TEXT")]
Exporting recordings of the Upload
component exports one piece of
unnecessary code that makes replay fail. Whenever you record a file upload, remember to
remove the call to clear()
as upload fields are special fields
that cannot be cleared. Also make sure that the replay window is wide enough for the upload
button to be visible (see driver.resizeViewPortTo()
), otherwise you
will get an exception when running the test.
Firefox needs to have focus in the main window for any focus events to be
triggered. This sometimes causes problems if something interferes with the
focus. For example, a TextField
that has an input
prompt relies on the JavaScript onFocus()
event
to clear the prompt when the field is focused.
The problem occurs when OS X considers the Java process of an application
using TestBench (or the node service) to have a native user interface
capability, as with AWT or Swing, even when they are not used. This causes
the focus to switch from Firefox to the process using TestBench, causing
tests requiring focus to fail. To remedy this problem, you need to start
the JVM in which the tests are running with the
-Djava.awt.headless=true
parameter to disable the
user interface capability of the Java process.
Note that the same problem is present also when debugging tests with Firefox. We therefore recommend using Chrome for debugging tests, unless Firefox is necessary.