A journey with OPA

Presented by Arnaud Buchholz
Presentation made with Reveal.js

Agenda

Sample application

• A simple todo list
• Developed to illustrate the OPA concepts
• 100% coverage
• Continuous Integration builds

training-ui5con18-opa

Why Automated Testing?

Need I say more?

Unit testing vs Integration testing

Maximize unit testing: they must be fast and they ensure code modularity.

Leverage integration testing: check the happy path then edge cases.

OPA Overview

One Page Acceptance Tests

• UI behavior testing
• JavaScript based
• Tightly integrated with UI5
• Asynchronous with active polling mechanisms
• Enables Test-Driven Development through abstractions

Compared to other automation frameworks

Selenium, Marionette or Puppeteer are framework agnostic, one must rely on the generated HTML to code automation (IDs, CSS selectors...).

OPA is designed by and for UI5 developers: one manipulates UI5 controls.

What is OPA?

OPA is a set of tools used to automate and validate UI (and it comes with backend mocking).

Tests are organized in Journeys, based on Pages to abstract the UI, and readable.

An example of one OPA test

							opaTest("should remove completed items", function(Given, When, Then) {
								// Arrangements
								Given.iStartTheApp();

								// Actions
								When.onTheAppPage.iEnterTextForNewItemAndPressEnter(S_NEW_ITEM_TITLE);
								When.onTheListOfItems.iSetTheItemToCompleted(S_NEW_ITEM_TITLE);
								When.onTheAppPage.iClearTheCompletedItems();

								// Assertions
								Then.onTheListOfItems.iShouldNotSeeAnyItemTitled(S_NEW_ITEM_TITLE)
									.and.iTeardownTheApp();
							});
						

Executing OPA tests

• As simple as running a web page
• A qUnit report documents execution results


• Application can be run in two different modes:
  • As a component within the test window
  • Inside an iFrame (slower but isolated)

Limits of OPA

• Designed to test one UI5 application
• Not designed to test backend

Pages & Journeys

Pages

They are used to abstract UI elements

Pages Examples

Pages Actions & Assertions

• onTheListOfItems

  
  									/* ... */
  									When.onTheListOfItems.iSetTheItemToCompleted(S_NEW_ITEM_TITLE);
  									Then.onTheListOfItems.iShouldSeeTheNewItem(S_NEW_ITEM_TITLE);
  									/* ... */
  								

• onTheFilterButtons

  
  									/* ... */
  									When.onTheFilterButtons.iClick(filters.COMPLETED);
  									Then.onTheFilterButtons.iShouldSeeTheButtonCount(filters.ALL, 4);
  									/* ... */
  								

Pages Examples

Pages Actions & Assertions

• onTheEditDialog

  
  									/* ... */
  									Then.onTheEditDialog.iShouldSeeTheTitleField();
  									When.onTheEditDialog.iClickClose();
  									/* ... */
  								

Pages implementation

							sap.ui.define([
								"sap/ui/test/Opa5"
							], function(Opa5) {
								Opa5.createPageObjects({
									onAbstractNamePage: {
										/*baseClass: ClassOfferingCommonHelpers*/,
										actions: {
											iExecuteAnAction: function() { return this.waitFor(/*...*/); },
											/*...*/
										},
										assertions: {
											iCheckAnAssertion: function() { return this.waitFor(/*...*/); },
											/*...*/
										}
									}
								});
							});
						

Makes an extensive use of this.waitFor

Filters=test/integration/pages/Filters.js

Journeys

• Relying on pages' methods, they describe the user experience within the application


• A journey is composed of tests


• Each test follows the pattern
  • Given: setup the initial state of the test
  • When: execute actions
  • Then: check assertions

Journey implementation

							sap.ui.define([
								"sap/ui/test/opaQunit"
							], function(opaTest) {
								QUnit.module("Journey name");
								opaTest("Test name", function(Given, When, Then) {
									Given.iStartMyApp();
									When.onAbstractNamePage.iExecuteAnAction()
										.and.iExecuteAnotherAction();
									Then.onAbstractNamePage.iCheckAnAssertion()
										.and.iTeardownMyAppFrame();
								});
								opaTest("Test name 2", function(Given, When, Then) {/*...*/});
								/*...*/
							});
						

Loading pages & journeys

• Ensure qUnit is loaded
• Load OPA, pages & journeys
• Start

							sap.ui.require([
								"sap/ui/test/Opa5",
								/* pages */
								/* journeys */
							], function(Opa5) {
								Opa5.extendConfig({
									/* Default settings */
								});
								QUnit.start();
							});
						

Anatomy of waitFor

Presentation of waitFor

• Main entry point to synchronize tests with the running application


• Locate and interact with UI5 controls

waitFor is asynchronous

waitFor-based members fill an execution queue
You can wait on the end of this queue using sap.ui.test.Opa5.emptyQueue

Synchronization in asynchronous tests

Since the test function is executed before the application is started, waitFor is required to synchronize.
For instance, to add a breakpoint:

							// Actions
							When.onTheAppPage.iEnterTextForNewItemAndPressEnter(S_NEW_ITEM_TITLE);
							When.onTheListOfItems.iSetTheItemToCompleted(S_NEW_ITEM_TITLE);

							When.waitFor({
								success: function() {
									debugger;
								}
							});

							When.onTheAppPage.iClearTheCompletedItems();
						

waitFor options

• waitFor offers a large set of options
• They can be grouped and sequenced:
  • (Configuring) timeout
  • Finding
  • Filtering
  • Checking
  • Interacting
  • Reporting
  • (Configuring) autoWait

Configuring - timeout

• timeout decides of the maximum waiting time (we use 15s)
• pollingInterval can be changed (defaulted to 400ms)

Finding

									iEditTheItem: function(sTitle) {
										return this.waitFor({
											controlType: "sap.m.ObjectListItem",
											/* ... */
										});
									}
								

Filtering (matchers)

									iEditTheItem: function(sTitle) {
										return this.waitFor({
											controlType: "sap.m.ObjectListItem",
											matchers: [new Properties({
												title: sTitle
											})],
											/* ... */
										});
									}
								

Checking (check)

									iShouldNotSeeAnyItemTitled: function(sTitle) {
										return this.waitFor({
											controlType: "sap.m.ObjectListItem",
											check: function(aItems) {
												return aItems.every(function(oItem) {
													return oItem.getTitle() !== sTitle;
												});
											},
											/* ... */
										});
									}
								

Interacting (actions)

									iSetTheTitleTo: function(sTitle) {
										return this.waitFor({
											id: "title",
											actions: [new EnterText({
												text: sTitle
											})],
											/* ... */
										});
									}
								

Reporting (success / error / errorMessage)

• Final step of the waitFor, receives resultset
• Avoid testing controls' state in success function
• Can chain to a subsequent waitFor

							iShouldSeeAGivenNumberOfItems: function(iCount) {
								return this.waitFor({
									controlType: "sap.m.ListBase",
									matchers: [new AggregationLengthEquals({
										name: "items",
										length: iCount
									})],
									success: function() {
										Opa5.assert.ok(true, "The list shows " + iCount + " items");
									},
									errorMessage: "The list doesn't show " + iCount + " items"
								});
							}
						

Configuring - autoWait

• Not enabled by default
• When enabled, waitFor monitors pending tasks requests, timeouts, promises, UI navigation...
  and includes the Interactable matcher
  Controls states are tested to check that they are 'available' and 'interactable'


• Use sap.ui.test.Opa5.extendConfig to set it globally
• Can be turned off in a specific waitFor
  For instance if you want to check that a button is disabled

Mocking Backend

The need for a backend

When the application has a backend counterpart, it can't run without being connected to it.

However, tests have to rely on a stable dataset and some features might be dangerous.

Introducing the MockServer

The MockServer is a software component that captures AJAX requests and either answer them or let them reach the backend.

Configuring the MockServer

• It requires the metadata to know the entities and relationships exposed by the ODATA service
• It initializes the entity sets by generating them or loading JSON files

							_oMockServer = new MockServer({
								rootUri: "/odata/TODO_SRV/"
							});
							_oMockServer.simulate("model/metadata.xml", {
								sMockdataBaseUrl: "model/"
							});
							_oMockServer.start();
						

MockServer entities

At any time, one can manipulate the entities

							var aExisting = _oMockServer.getEntitySetData("TodoItemSet"),
								sGuid = "0MOCKSVR-TODO-MKII-MOCK-00009999";
							// Adding a new entity
							aExisting.push({
								"Guid": sGuid,
								"Title": "Generated",
								"Completed": false,
								"DueDate": "/Date(" + new Date(2099, 11, 31).getTime() + ")/",
								"__metadata": {
									id: "/odata/TODO_SRV/TodoItemSet(guid'" + sGuid + "')",
									uri: "/odata/TODO_SRV/TodoItemSet(guid'" + sGuid + "')",
									type: "TODO_SRV.TodoItem"
								}
							});
							_oMockServer.setEntitySetData("TodoItemSet", aExisting);
						

Default MockServer hooks

By default, the MockServer hooks a lot of
ODATA operations :

• $batch
  (transparently split into individual requests and consolidates results)
• Create, Read, Update and Delete
• Query parameters: paging, filtering, sorting
• Resolving navigation properties
  One level only

But function imports are not supported

Altering the MockServer hooks

An hook is defined with:

• method: GET, POST, PUT...
• path: a regexp matching the API URL
  Using capturing group, you can extract url parameters
• response function: where the behavior is implemented

Altering the MockServer hooks

							var aRequests = _oMockServer.getRequests();
							aRequests.push({ // Creation of a todo list item
								method: "POST",
								path: CONST.OData.entityNames.todoItemSet,
								response: function(oXhr) {
									/* ... */
									// Initialize some fields
									var oBody = JSON.parse(oXhr.requestBody);
									oBody[CONST.OData.entityProperties.todoItem.completed] = false;
									oBody[CONST.OData.entityProperties.todoItem.completionDate] = null;
									oXhr.requestBody = JSON.stringify(oBody);
									return false; // Keep default processing
								}
							});
							_oMockServer.setRequests(aRequests);
						

Adding new MockServer hooks

This is how function import can be implemented

							// Clear Completed
							aRequests.push({
								method: CONST.OData.functionImports.clearCompleted.method,
								path: CONST.OData.functionImports.clearCompleted.name,
								response: function(oXhr) {
									/* ... */
									oXhr.respond(200, {
										"Content-Type": "application/json;charset=utf-8"
									}, JSON.stringify({
										d: oResult
									}));
									return true; // Skip default processing
								}
							});
						

MockServer hooks Tips & Tricks

• The MockServer does not need to be 100% equivalent to the backend
• Newly added hooks are executed first (LIFO)
• You may also use attachBefore or attachAfter callbacks triggered before or after request processing