More from the Series related to the UI5 Excel Upload Control
In a previous blog post, I introduced a UI5 reuse component that simplifies the process of uploading Excel files in UI5. The main objective was to support all current maintenance versions of UI5 and as many usage scenarios as possible. To automate testing for these scenarios, I used wdi5 in conjunction with GitHub Actions. You can find all the currently
supported scenarios in the documentation.
Setup
The basic setup involves a monorepo in GitHub with a folder that contains all the supported scenarios and a
CAP server that provides the data. The individual UI5 apps consume the latest version directly from the repository. To install the dependencies, we used pnpm. We used these apps for development and testing.
For an overview of which apps are executed with which version and which tests, the
testapps.json was created for this purpose, which later scripts fall back on.
As Parent Attributes the scenario is described.
The attributes assigned to it are:
- appTitel -> Title display in the App Header
- port -> Port on which the app runs on,in theory all apps could run side by side
- versionMinor -> Minor Version of UI5
- testMapping -> all wdi5 test files this app should run
- copyVersions -> into which versions should the scenario be copied
In "copyVersions" the same attributes are used to create the apps. In addition to this, the exact UI5 version is added.
Theoretically, each scenario and UI5 version could have its own tests.
Setup Apps
As you can see in the packages folder, there is always only one version of the respective scenario. (the latest maintenance version 1.108).
So that the other versions can also be used locally and in GitHub Actions, the script
copy-example-apps.js was created so that these scenarios are copied in all other maintenace versions.
As described above, the data from the json file is used to copy the apps.
The result will then look like this:
As you can already also see from the grayed out folders, these are also added to .gitignore.
All apps are designed to work from maintenance versions 1.71 to 1.108. That's why they can be easily copied. Only for version 1.71 and 1.84 the theme had to be
changed to "sap_fiori_3".
The attributes that were changed was:
- ui5 version
- Port number
- package.json attribute "name
- App title
The name in the package.json of the respective app was only changed from "ordersv4fe108" to "ordersv4fe96", for example.
This has especially the advantage to start the app directly with pnpm:
pnpm --filter ordersv4fe96 start
Setup wdi5
The configuration file wdio-base.conf.js with wdi5 or wdio is aligned to test only one app or url.
But since the file is in a javascript file and the config is a simple object in this file, it is easy to make this file more dynamic with javascript.
Now we can use the data from the testapps.json file to dynamically call only the tests of the respective app via the
wdio-base.conf.js .
The code extracts the specs and port from the file and puts them into the object called by wdio.
Now it is possible with pnpm to call the test with parameters exactly only for a special version of an app:
wdio run ./test/wdio-base.conf.js -- -- ordersv4fe 108
pnpm --filter ui5-cc-spreadsheetimporter-sample test -- -- ordersv4fe 108
wdi5 Tests
For me personally it is still hard to write wdi5 tests.
At least the initial setup has been simplified a lot with
UI5 Journey Recorder which allows you to quickly build a basic framework.
For the tests, similar to the apps, I wanted to have only one spec file and not a separate spec file for each scenario.
Unfortunately, this only worked to a limited extent.
I could at least reuse the test scripts for the Fiori Element Apps, since there are differences between V2 and V4.
- Call List Report Page
- Navigate to Object Page
- Enter the edit mode
- Open Excel Upload dialog
- Upload Excel file
- Send draft to backend
- Save draft
- Navigate to the Sub Object Page
- Validate if the data was uploaded correctly
GitHub Actions
We have achieved that we can call many different scenarios individually.
Now we want to execute this automatically on every pull request.
Again, we do not want to create a separate workflow for each test.
For this purpose there is the
Matrix feature in the GitHub Actions.
This makes it possible to execute a worfklow repeatedly with different parameters. A classic example would be to test something with node versions 14,16 and 18.
However, we can use this to test the different scenarios with each UI5 version.
It helps us that we can call them specifically with pnpm.
In the
workflow file for the wdi5 Tests, the matrix attributes are now defined as follows:
matrix:
scenario: ["ordersv2fe", "ordersv4fe", "ordersv2fenondraft", "ordersv2freestylenondraftopenui5", "ordersv2freestylenondraft"]
ui5version: [108, 96, 84, 71]
exclude:
- scenario: ordersv4fe
ui5version: 71
Only the Fiori Elements V4 with Version 71 is currently excluded from the test.
All five scenarios are executed now with all four UI5 versions.
This then results in 5 scenarios x 4 UI5 version - 1 included = 19 tests
In the rest of the file, the entire enviroment is built up to the test:
- pnpm installed
- pnpm install executed
- Copied the test apps
- Built the UI5 Excel upload component
- Started the CAP server
Now we can s
tart the app with the attributes from the matrix:
pnpm --filter ${{ matrix.scenario }}${{ matrix.ui5version }} start:silent&
which will result in
pnpm --filter ordersv4fe108 start
After that we can
start the test like:
pnpm --filter ui5-cc-spreadsheetimporter-sample test -- -- --headless ${{ matrix.scenario }} ${{ matrix.ui5version }}
which result in
pnpm --filter ui5-cc-spreadsheetimporter-sample test -- -- ordersv4fe 108
And as you can see here from the runtime, all tests in the matrix run in parallel, so a complete test runs under 5 minutes.
More Information
Further Links: