Non-visual code can be JUnit tested as usual. But as a visual UI framework testing DomUI itself brings some challenges. While still a work in progress this is what is currently done to help with testing the visual and browser based aspects of DomUI.
The visual tests all use Selenium WebDriver to run tests. To run these we actually need two parts operational:
The Maven build runs these tests as Integration Tests. These can be found automatically (by Maven) because the class names all start with IT, like ITHtmlEditorComponentTest. Them being Integration Tests means that they run only after all "normal" tests have run, and after the whole web application has been constructed. This works as follows:
You can test against any Selenium-supported browser by setting properties inside ~/.test.properties, or passing them as Java properties to the JVM. But by default the tests will run using the Chrome Headless browser. This means that chrome and chromedriver need to be installed on whatever station DomUI is built on, as follows:
Since Chrome 59 we can also use Chrome in headless mode, and as PhantomJS development has been abandoned this is now the default.
There are some issues with using chrome. The most important issue is that ChromeDriver/Chrome does not properly take screenshots. Unlike the other drivers chrome takes only partial screenshots of the page, and that breaks some tests and makes bugs harder to find.
To circumvent this issue the DomUI wrapper around WebDriver has a special implementation of the code that creates a screenshot for Chrome. The code is described on Stackoverflow.
You can also use PhantomJS as the headless test platform. Just install the "phantomjs" executable in some directory in your PATH, and define webdriver.hub=phantomjs in .test.properties or on the command line (-Dwebdriver.hub=phantomjs).
Sadly enough PhantomJS is no longer supported because the main developer quit 8-/
Please install phantomjs from the website, and do not use your distribution's version of it (so do not use apt-get). The distributions often distribute handicapped versions causing odd test failures.
I moved to Phantomjs because its alternative, htmlunit, does not allow screenshots to be taken from the pages, and this makes a lot of tests hard to use. But it can still be used, with the effect that some tests will not really work.
The DomUI code wraps Selenium in a few helper classes that help with easier testing of DomUI code. See the provided JUnit tests for details. These classes are thin wrappers around WebDriver itself so missing functionality is easily added.
The base class to write Selenium tests is called AbstractWebDriverTest, and it handles everything to access a webdriver wrapper: just call wd() inside any test to get the proper WebDriver wrapper.
For this we can use Selenium's ability to take screenshots. Using screenshots of a rendered page we can load the screenshot, then use Selenium's knowledge of the position and size of a web page element to extract from the screenshot the actual rendering of the component as a bitmap. This bitmap can then be further analyzed.
The UI tests that run during the build will make screenshots for those tests that fail. These screenshots are stored inside the [module]/target/failsafe-reports directory as classname_testname.png, for instance:
If the build fails all of the failsafe-reports directories are collected and tarred, and these are copied to the deployment server so that they can be obtained (they are copied to deployer@xxx/reports.tgz).
Travis-CI has phantomjs default in its image, but that is an older version (2.0.0). To ensure that we have the same results locally and in the build the build script will download version 2.1.1 of phantomjs and cause it to be used by setting the PATH to it.