Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

Some of you might’ve already explored the youngest member of our UI5 family on GitHub: UIVeri5. So, it’s high time to introduce this new framework to you!


There are many testing frameworks out there and some of them are targeting specific UI technology or a specific layer of the testing pyramid. For UI5, we suggest and heavily use internally QUnit as a unit testing framework. For app tests, we offer OPA5. But we were missing an end-to-end (E2E) framework. This has traditionally been in the domain of manual UI testing. Of course, there’s the highly popular Selenium and many other great browser-automation frameworks, such as Puppeteer and Cypress, or OS-level automation ones, like Sikuli. Unfortunately, using them with modern, JS-centric UI framework like UI5 can be harder than it should.

The major real-world belief is that automated UI testing is considered unreliable and it is avoided in favour of manual tests. However, manual tests cannot be used as regression testing. The ability to automate and reliably execute a core set of E2E scenarios could make a significant difference to the quality of the product.

The idea of a Selenium-based framework that makes UI testing reliable was the dream based on which UIVeri5 was born: the E2E test framework for OpenUI5 and SAPUI5 apps!

Originally developed for our internal UI5 testing activities, the framework quickly found new customers within SAP. The feedback we got from them confirmed that UIVeri5 delivers real benefits and motivated us to make it open source and available to the whole UI5 community.

Key Benefits

I can come up with a long list of capabilities and benefits but let me share the major points that differentiate UIVeri5 from the classical home-grown, Selenium-based framework.

Synchronization with UI5 Rendering

UIVeri5 synchronizes the test execution with the UI5 rendering in the browser. This avoids the need for manual coding waits and sleeps in the test. It leads to tests that are reliable by design, without requiring deep expertise to create them.

Tests in JavaScript

Tests in UIVeri5 are written in JavaScript, which nicely matches the UI5 app. Having the tests in the same language as the app makes is easy for the app developer to comprehend and convenient to maintain the tests, together with the main code base. Even further, this removes the technical obstacles and opens the door to agile development practices, like Test-Driven Development.

Synchronous Tests

UIVeri5 uses WebDriverJS as Selenium binding and builds on the flow handling that it provides. As a result, the test looks synchronous and does not need explicit callbacks or promise chaining. This becomes a huge benefit for the automation experts with Java background.

Control Selectors

A major issue in every UI test is the identification of the elements. Typically, this is achieved with ID, CSS or XPATH selectors that all work on the DOM level. This approach works well with typical web pages or UI frameworks that augment the DOM, but it has its limitations when working with frameworks like UI5 that encapsulate the DOM handling in JavaScript. To overcome such problems, we provide control locators that allow identifying the control based on its properties or relations.


UIVeri5 is inspired by Protractor, the E2E testing framework for Angular apps. Protractor is a very popular testing tool that a lot of developers are familiar with. So, it’s good to hear that for most parts, the Protractor knowledge is directly applicable to UIVeri5.

UIVeri5 is also Node.js-based that makes it easily combined with our UI5 build and development tooling.


We are excited to finally release UIVeri5 under the Apache 2.0 license, just like OpenUI5, so that everyone in the UI5 community can utilize our terrific testing tool. And, as UIVeri5 is hosted on GitHub, it’s also a piece of cake to fork and extend it to support specific use cases.

We would like to hear your feedback! Leave a comment under this post or ask a question on SAP Q&A. Found an issue? You are welcome to report it on GitHub.