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: 
Active Contributor


Ah… Automated testing… What a bless!
Remember when we had to manually test the application we developed?
And with every single change we did, we had to execute them again to make sure nothing got broken?
Soon enough we had a “testing day”, which turned into a “testing week” before each release, which turned into a time-consuming nightmare.

Well, you are in luck, those days are over 🙂
Nowadays we have automated tests that are executed with a click of a button (and with a proper CI/CD solution, automatically on every “push” to Git).
They also run on different browsers and on different release versions, so we no longer need to test every possibility manually!

You would have thought everyone was doing automated testing these days, right?
Unfortunately, we discovered that it’s still considered too much time-consuming and therefore costly and that is why a lot of Fiori apps are still being tested manually.

I decided to write this blog to explain why automated testing for your SAP Fiori app is so important, so you could use it to convince your customer it’s worth investing time in!
I will also showcase what are the tools provided by SAPUI5 and SAP Web IDE in this area that can significantly help you.

Why automated testing?

  1. Quality.
    Bugs will always find a way into your application. However, with good automated tests, they should be found prior to the release.
    Even your best QA engineer can’t test every single possible combination of steps, with every configuration, in a reasonable amount of time, with no mistakes along the way.
    Yet, an automated test can run on various configurations in parallel, for as many times as needed, compare the results to the expected behavior, and report the results.
    This means an automated test covers more code and more flows, without mistakes. It finds more bugs and by doing so, increases the quality of your app!

  2. Time and money.
    Every time the source-code changes, tests should be executed.
    Doing this manually is very time-consuming and costly.
    An automated test, once created, can be repeated over and over with no additional cost, and you know computers are much faster than humans (I’m afraid we already lost this war).
    Any amount of time you save translates directly to cost.

  3. Load testing.
    Even the largest QA department can’t perform a test with thousands of users.
    Automated testing can simulate tens, hundreds or thousands of virtual users interacting with your application.
    This can help build your confidence before your go-live…

  4. Everyone is happy!
    Ok maybe it’s a bit of a stretch but think of the poor person that used to test the same steps over and over again. With automated testing he is free! He can concentrate on creating new automated tests, or on complex features or other challenging tasks, which improve his skills and confidence.

Continuous Integration/Delivery

Having automated tests is the basis for a useful and productive CI/CD process.

With automated tests as part of your CI/CD pipeline, you can move from a state where you are too afraid to do any change in your application and therefore change it rarely and cautiously, to a state where you make changes frequently, safely and quickly, because your tests increase your confidence.

Also, we see that automated testing is highly integrated into existing enterprise-grade CI/CD toolsets.

For more information, check this white paper about Automated Testing: The Glue that Holds DevOps Together.


How to get started

Let’s say you’re ready to let go of your manual testing and join the beautiful world of automation. How should you start?

The first step is to become familiar with the basics of JavaScript unit testing with QUnit, which is a powerful and easy-to-use JavaScript unit-testing framework.
Then, you should become familiar with One Page Acceptance (OPA), which is an API for SAPUI5 controls, helpful for testing user interactions, integration with SAPUI5, navigation, and data-binding.

Lucky for you, SAPUI5 created an excellent tutorial that demonstrates how to write tests using QUnit, OPA, and the mock server. Additionally, you will learn about testing strategies, Test Driven Development (TDD), and much more. Highly recommended!



Developers can use one of the provided templates in SAP Web IDE as a starting point for their app.

Not many developers are aware that the SAP Fiori templates already contain a vast number of automated tests, both unit tests with QUnit and integration tests with OPA!

These tests cover much of the existing functionality to make sure it won’t break, and can also be used as a reference for your future tests, since they are written according to SAPUI5’s guidelines and best-practices.


You can find all the test information per template in the SAPUI5 documentation:

Worklist Template

Master-Detail Template

In addition to these great templates, SAP Web IDE offers commands to help you quickly create empty QUnit Test, OPA Page, and OPA Journey.


And if you're using the SAPUI5 Application template, you can right-click it and choose to create a new Test Structure. This will create a "test" folder with Qunit and OPA resources.


So these can also be used to assist with the creation of automated tests!

We know it seems to take a lot of time at first but once you get the hang of it you are going to write tests much faster. Just like coding.

Do you have more ideas for improvements in this area?

Use the power of the community and share your thoughts in the comments section.


Happy testing 🙂