 |  |  |  |  |  |  |  |
| Version 7.1.2 |
Webswing and JPro are two highly interesting solutions that bring Swing and JavaFX desktop applications into a browser. The underlying technologies, concepts and goals differ significantly, but the challenge for QF-Test mainly boils down to the same thing: There are two SUT clients that need to be tested together in a coordinated way.
Migrating existing applications is one of the most common scenarios, so the ability to reuse existing QF-Test tests
for the Swing or Java desktop application is crucial. This is one reason why testing through the browser alone
is not sufficient. The other reason is that in the browser QF-Test only sees either a CANVAS node
with colored pixels (Webswing) or a hierarchy of very similar DIV nodes (JPro). Though the latter
is at least moderately useful for testing and may become interesting for special cases like load testing, it is
still very limited compared to the deep access QF-Test has to Java applications.
Enter "JiB" - QF-Test's solution for "Java in Browsers".
Note In addition to QF-Test engine licenses for Swing and/or JavaFX, JiB support requires QF-Test licenses for the web engine.
A demo test suite for Webswing is provided for a better understanding of the concepts described in the section below. You can open it via the menu »Help«-»Explore example test suites...«, entry "Webswing SwingSet Suite".
With the JiB concept QF-Test treats the Swing or JavaFX application as the primary SUT. Nearly all interaction is triggered through the respective Swing or JavaFX SUT engine. QF-Test also opens a browser window and uses its web engine to interact with this frontend through which the application is displayed and through which the user interacts with it.
There are two modes of interaction between QF-Test and the application:
QF-Test can keep the event handling entirely within the Swing or JavaFX application. In that mode the browser serves only as a trigger to launch the application, as a reference for the user and for handling special cases where the workflow in the application had to be adapted to use web interfaces, most notably for file upload and download.
This mode is very similar to testing a plain Swing or JavaFX application, event simulation happens in an identical way. Images for image checks are taken via Swing or JavaFX off-screen-rendering to a memory buffer, also identical to the desktop version.
What the above doesn't cover is the verification that the Webswing or JPro integration actually works end-to-end as expected, i.e. that the user really sees the interface as expected and that the user can interact with the application via mouse and keyboard through the browser. Though it is debatable to which degree underlying technologies should simply be trusted or covered by one's own tests, the ability to perform real end-to-end tests via the browser is a very important aspect in this scenario.
To that end QF-Test can redirect the actual replay of mouse and key events to the browser via a number of option settings. Tests are still written and executed against the Java application, component recognition works unchanged and QF-Test performs all the necessary synchronization and setup like scrolling the target component visible or implicitly opening tree nodes. At the final step the Swing or JavaFX engine doesn't replay the mouse or key event itself but uses a special connection instead to forward the event information to the QF-Test web engine, then waits for the event to be performed there and received back into the Java application via Webswing or JPro.
The final building block for end-to-end tests is verification of what gets displayed in the browser via image checks. Instead of using off-screen-rendering, QF-Test can delegate taking images to the web engine which captures a screenshot of the respective region in the browser window. These images will vary from the Java off-screen variants in subtle ways for font-rendering or anti-aliasing which can be accommodated for by using QF-Test's image check algorithms as described in chapter 57.
Tests using Java-mode are very robust and more efficient. Our recommendation is to use that mode for migrating existing tests and for running the bulk of the functional tests. These should be supplemented with various tests using web-mode to ensure end-to-end reliability. As a rule of thumb, testing the same UI with different values and the focus on functionality should mostly use Java-mode. Testing different components with the focus on interaction should use web-mode.
Procedures for switching between the various option settings are provided in the package
qfs.jib of the standard library suite qfs.qft.
| | | | | | | Last update: 3/13/2024 Copyright © 1999-2024 Quality First Software GmbH |
