Performing Integration Tests with One-Page Acceptance (OPA5) Tests

Watch this short video to learn about OPA5, its advantages, and limitations.

As we have already seen in the QUnit-lesson, the start of the OPA-tests is also implemented using a different html-file. The file is called the opaTests.qunit.html file and contains the bootstrapping code for the execution of OPA-tests. The bootstrapping file is generated by the SAP Business Applicaton Studio during project generation.

Let us now look at bootstrapping, library loading, and test initiation.

Note

You usually have various tests in a UI5 project. Tests are usually separated by their context - for example, tests like make sure that when a list item is selected, the details of the selected item are shown and tested (when the status of the item has a specific value, a specific icon is shown). These different tests are usually connected to a journey. A journey consists of a series of integration tests that belong to the same context such as navigating through the app. Similar to the QUnit test implementation, OPA5 uses QUnit, that is why we first set up a QUnit module Navigation that will be displayed on our result page. The journey is implemented in the file, NavigationJourney. Of course you may have also files with different names containing a journey implementation.

Each test case scenario is implemented in a different JavaScript file.

The following two figures describe the anatomy of an OPA5 test case.

The above figure shows a test implementation. The test case is set to check whether or not the component with the namespace sap.training.optest.integration.button can be loaded or not.

The function opaTest is the main aspect for defining integration tests with OPA. Its parameters define a test name and a callback function that gets executed with the following OPA5 helper objects to write meaningful tests that read like a user story.

• Given: On the given object, we can call arrangement functions like iStartMyUIComponent to load our app in a separate iFrame for integration testing.
• When: Contains custom actions that we can execute to get the application into a state that allows us to test the expected behavior.
• Then: Contains custom assertions that check a specific constellation in the application and the teardown function that removes our iFrame again.

The OPA5 framework provides us different possibilities to get a reference to a UI control on the view. One option is to get a reference by the id of the control. The following figure shows the key aspects involved in the retrieval of a control by ID.

Note

Ensure that each control inside the view implementation has a stable id. Inter alia using stable id's will ensure that your tests will work. To learn more about stable id, refer to the SAPUI5 documentation, https://ui5.sap.com/#/topic/79e910e6a0d949c7acb051b33170bebc.

Besides the retrieval of a UI control by id, it is also possible to use so called matchers. The following figure shows matchers retrieving a control without an ID but using a matcher. In this case, a sap.ui.test.matchers.PropertyStrictEquals is used. We want to get all controls of type sap.m.Button, where the property text contains the value Press me. You can find more matcher implementations in the namespace sap.ui.test.matchers of the SAPUI5-API-documentation (https://ui5.sap.com/#/api/sap.ui.test.matchers).