Recently I built an extension app which featured a dynamic checklist for users to complete. Questions appear based on answers already given, and there are a large number of different scenarios, each with a different question set. Some questions are unique to a particular scenario, but many others are shared across scenarios.
In order to maintain my sanity I decided to set up automated testing. My concern was that changes and fixes made for one scenario could cause issues with another scenario. With automated testing I can test all of them every time I make changes.
As I wanted to test at the UI-level I was looking for end-to-end testing, replicating a real user journey. This is distinct from unit tests, for example, which cover a simple ‘unit’ like a function.
I decided that wdi5 (pronounced vee-d-i-5) was a good fit for my requirements. It’s a plugin for Webdriver.IO, a popular automation framework. Whereas Webdriver.IO is agnostic when it comes to UI technologies, wdi5 is optimised for use with SAPUI5 and OpenUI5. It brings specific APIs which you can use to interact with your UI5 apps in your test scripts.
I thought I should share some of the things I learnt during this project. I do so not as an expert on automated testing in general or wdi5 in particular (I’m not!), but rather as experienced UI5 developer looking to make more use of automated testing in my day to day work. The perspective of the novice is different to that of subject matter experts, and the latter might not anticipate the questions and problems that the former face.
If you too are new to wdi5 you might not know that:
You can use wdi5 in SAP Business Application Studio (BAS)
wdi5 tests run in-browser. The browser could be on your own machine or it could be virtual. If you’re a BAS user you can install the Headless Testing Framework plugin and then run your wdi5 tests from within BAS. The tests are running in headless Firefox. If you take this approach you need to take care that the Firefox version listed in your Webdriver.IO config file (wdio.conf.ts) matches the one that BAS is using. Every now and then SAP will upgrade the Firefox version in the plugin, and you will get an error stating ‘Unable to find a matching set of capabilities‘. When this happens just check what the new Firefox version is (“firefox -v” at the CLI) then update your config accordingly.
You might want to bail
I want to know as soon as any of my tests fail. By setting the bail property to true, execution will finish as soon as the first failure occurs. If you use mocha as test runner, you can set this in the mochaOpts parameter in your config file (wdio.conf.ts).
It’s easy to debug your tests
If you open the JavaScript Debug Terminal, and run your tests from there, processing will pause at the breakpoints you add in your test files. If you are using BAS you can do this from the Command Palette.
You should probably put the kettle on
My 40ish tests take about an hour to run. This requires some planning, like starting them before you take your lunch break. I did find that tweaking the tests can make a big difference. Some wdi5 functions are faster than others. For example, I found the getChildren method was quite slow, especially when the controls weren’t visible on screen (and therefore not in the DOM). It’s also possible to run tests in parallel.
Everything is asynchronous
In your tests the function calls are asynchronous, and you need to await each one. This is true even if the corresponding UI5 function is synchronous e.g getText().
wdi5 
TypeScript
You can write your tests in TypeScript (i.e. as .ts not .js files). See here if you want to know why this is desirable.
You need to get scrolling
Your tests can only interact with screen controls that are shown on screen. You need to use scrolling functions like scrollIntoView() or browser.scroll() to ensure that the control you need is visible.
It’s easy to screenshot your errors
When a test fails the root cause isn’t always obvious. Was there an error? Was the control we tried to interact with even visible on screen? I love that you can always capture a screenshot if there was an error, so you can see exactly what the screen looked like at that moment. I did this by calling the browser.screenshot() function in the afterTest handler.
If you are ready to write your first wdi5 tests, keep the points above in mind and check out these resources:
Resources
wdi5 GitHub Documentation
Use WDIO and WDI5 for testing UI5 apps
state of testing in UI5: OPA5, UIVeri5 and wdi5
Testing UI5 Apps with wdi5 – Zero to Hero to Continuous Integration
Recently I built an extension app which featured a dynamic checklist for users to complete. Questions appear based on answers already given, and there are a large number of different scenarios, each with a different question set. Some questions are unique to a particular scenario, but many others are shared across scenarios.In order to maintain my sanity I decided to set up automated testing. My concern was that changes and fixes made for one scenario could cause issues with another scenario. With automated testing I can test all of them every time I make changes.As I wanted to test at the UI-level I was looking for end-to-end testing, replicating a real user journey. This is distinct from unit tests, for example, which cover a simple ‘unit’ like a function. I decided that wdi5 (pronounced vee-d-i-5) was a good fit for my requirements. It’s a plugin for Webdriver.IO, a popular automation framework. Whereas Webdriver.IO is agnostic when it comes to UI technologies, wdi5 is optimised for use with SAPUI5 and OpenUI5. It brings specific APIs which you can use to interact with your UI5 apps in your test scripts.I thought I should share some of the things I learnt during this project. I do so not as an expert on automated testing in general or wdi5 in particular (I’m not!), but rather as experienced UI5 developer looking to make more use of automated testing in my day to day work. The perspective of the novice is different to that of subject matter experts, and the latter might not anticipate the questions and problems that the former face.If you too are new to wdi5 you might not know that:You can use wdi5 in SAP Business Application Studio (BAS)wdi5 tests run in-browser. The browser could be on your own machine or it could be virtual. If you’re a BAS user you can install the Headless Testing Framework plugin and then run your wdi5 tests from within BAS. The tests are running in headless Firefox. If you take this approach you need to take care that the Firefox version listed in your Webdriver.IO config file (wdio.conf.ts) matches the one that BAS is using. Every now and then SAP will upgrade the Firefox version in the plugin, and you will get an error stating ‘Unable to find a matching set of capabilities’. When this happens just check what the new Firefox version is (“firefox -v” at the CLI) then update your config accordingly.You might want to bailI want to know as soon as any of my tests fail. By setting the bail property to true, execution will finish as soon as the first failure occurs. If you use mocha as test runner, you can set this in the mochaOpts parameter in your config file (wdio.conf.ts).It’s easy to debug your testsIf you open the JavaScript Debug Terminal, and run your tests from there, processing will pause at the breakpoints you add in your test files. If you are using BAS you can do this from the Command Palette.You should probably put the kettle onMy 40ish tests take about an hour to run. This requires some planning, like starting them before you take your lunch break. I did find that tweaking the tests can make a big difference. Some wdi5 functions are faster than others. For example, I found the getChildren method was quite slow, especially when the controls weren’t visible on screen (and therefore not in the DOM). It’s also possible to run tests in parallel.Everything is asynchronousIn your tests the function calls are asynchronous, and you need to await each one. This is true even if the corresponding UI5 function is synchronous e.g getText().wdi5 TypeScriptYou can write your tests in TypeScript (i.e. as .ts not .js files). See here if you want to know why this is desirable.You need to get scrollingYour tests can only interact with screen controls that are shown on screen. You need to use scrolling functions like scrollIntoView() or browser.scroll() to ensure that the control you need is visible.It’s easy to screenshot your errorsWhen a test fails the root cause isn’t always obvious. Was there an error? Was the control we tried to interact with even visible on screen? I love that you can always capture a screenshot if there was an error, so you can see exactly what the screen looked like at that moment. I did this by calling the browser.screenshot() function in the afterTest handler. If you are ready to write your first wdi5 tests, keep the points above in mind and check out these resources:Resourceswdi5 GitHub DocumentationUse WDIO and WDI5 for testing UI5 appsstate of testing in UI5: OPA5, UIVeri5 and wdi5UI5’s unified test tech stackTesting UI5 Apps with wdi5 – Zero to Hero to Continuous Integration Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
