UI Integration Tests Page - mrietveld/jbpm GitHub Wiki

Home ▸ 1-Pager: UI Integration Tests
2015-04-08

We (KIE) are missing community-side UI integration tests. In order to "get the train rolling", we need to build some simple UI Integration tests and have them in our build.

The technologies to use seem to be the following:

• Cargo for container/deployment management?
  • Arquillian may initially be used in the PoC since it has better fine-grained control
• WebDriver
• GhostDriver
  • • PhantomJS

Jiri Locker from QA has shared some very helpful information:

GWTMockito

I am skeptical with respect to GwtMockito being the best tool for integration testing. I see GwtMockito primarily as a good tool to unit test GWT UI code[1]. When it comes to integration test I would try to test the real application deployed in a real environment. I guess Arquillian could be used to test backend services in container. But if GUI is your main concern then I would probably go for WebDriver (API) + GhostDriver (WD API implementation running PhantomJS headless browser). Arquillian could be used in this scenario to help manage container lifecycle, too.

[1] The assumption is that you try to mock backend dependencies whenever it is possible (those should be unit-tested separately).

Common UI Problems

Most frequently some component is completely broken or breaks under certain condition, e.g:

• editor for certain asset type does not open,
• some other screen or perspective stops working (under certain condition),
• validation fails (even though the file is OK but the validation result is affected by completely different file),
• project build fails unexpectedly (that usually indicates a different problem),
• file upload doesn't work (uploaded file is OK but the upload servlet is bugged),
• guided editor displays different content after re-opening.

To categorize this: UI code should be resilient to error condition on server (it should notify the user and continue to respond) and it should validate user input and disallow submitting invalid data, or modelling invalid rules whenever possible.

GWT Coding best practices

You can take a look at following gists if you want to learn about challenges that arise when writing GwtMockito tests. Most frequently it is necessary to convert "new MyWidget()" to "GWT.create(MyWidget.class)" or use @UiField.

• Example 1: CopyPopupTest
• Example 2: ArtifactListPresenterImplTest
• Example 3: UploadFormTest

Otherwise, if you go for integration tests with browser then I think the Java UI code doesn't matter, with one exception -- it really helps to use CSS classes and IDs on important elements so that it is easier to locate them in the browser.

• A robust/stable set of UI Integration tests in the community build

• PoC
• Initial UI integration tests

• UI Coding best practices
  • Internally documented and enforced
• A full suite of UI integration tests

Not started

Start in July 2015 -- there's simply too much other work to do anything before that

7.0.x Deadline

This is an iterative middle-term (not short-term, not long-term) project with the following steps:

1. Create a Proof-Of-Concept project that explores and identifies the technologies to use
2. Create a few initial UI integration tests that can be incorporated into the build
3. Identify, share and enforce UI coding best practices to make UI integration tests possible
4. Create a larger suite of UI integration tests

• QA
  • feedback
  • idea's, possible cooperation?