Skip to Content
Technical Articles
Author's profile photo Mauricio Lauffer

Modern JavaScript testing frameworks with Fiori/UI5 – Overview

This is going a blog series where I want to show how modern JavaScript test frameworks could be used to test SAP Fiori/UI5 apps and libraries. To make it more digestible, I’ll slip it into 4 parts:

After 10+ years of helping the js community, Karma has been deprecated and won’t get new features. This affects the UI5 community because Karma is the official and most used test runner for Fiori/UI5 (Karma-ui5).

Unit testing Fiori apps and UI5 libraries have always been limited to the duo QUnit/Karma. QUnit is one of the oldest javascript test frameworks, it’s been used by the ancient Aztecs even before the Spaniards had taken it to Europe…

With these two things in mind, I decided to explore new ways to test Fiori/UI5 code using modern tools. Three javascript test frameworks made my list: Jest, Vitest and Node Test Runner. Not just because they’re new (Jest is old), but because the majority of the js community loves them (or have the potential to become the most loved one). As a bonus, they can also be used to test Nodejs (and TypeScript) code, including CAP Nodejs (more on that in a future blog?). How cool would be to have the same testing framework for both frontend and backend?

More reasons: nobody has done it before. I don’t want to run any browser-based unit test. I don’t want to use anything that’s UI5 specific. I want to have the freedom to choose my tools, the ones that best fit my (company) needs, just like any other javascript developer out there. I want to be able to tap on and onboard any js developer/tester from the market, not somebody that has to know SAP just to write a test. I want to reuse the same resources to write tests not only for Fiori/UI5 apps but for (CAP) Nodejs  and any other web apps as well. How many js developers are in the market? How many SAP Fiori/UI5 do we have? I know, I know, for unit testing a developer/tester would still need to know UI5… You got my point.

Jest –

Created in 2013. It’s the most famous and most used today. It has a massive community supporting it. It’s a batteries-included testing library: it comes with code coverage, mocking features, code transpilation, assertion, etc. Because of that, you don’t need to install a lot of dependencies or configurations to start working with (like Mocha for instance).

What I like: easy to use!

What I don’t like: it pollutes Nodejs globals, auto-mocking everything, auto-transpile everything with Babel, memory leaks and no support for ESM. Its own dependency list is gigantic (200+ packages).

Vitest –

Created in 2021. It’s a fast-growing and fast-running test framework! It’s built for the modern js world. A lot of people are migrating from Jest to Vitest because it doesn’t have the same issues Jest has, and it’s a drop-in replacement using the same API. It’s batteries-included as well.

What I like: same as Jest, but doesn’t have Jest problems.

What I don’t like: online content is not as abundant as Jest, it might be hard to find documentation/examples for edge cases.

Node Test Runner –

Created in 2023. It’s a brand new native Nodejs testing library available on v16 and v18 as experimental and General Available (GA) on v20. No dependencies, it’s part of Nodejs itself which means you don’t need external packages anymore.

What I like: it’s part of Nodejs, not an external module. No overhead. It may eat all others!

What I don’t like: code coverage is still experimental on v20.


QUnit never made to the list 🙁 – State of JS 2022


As you may have noticed, all the options are Nodejs, not browser runners which makes it impossible to test Fiori/UI5 code out of the box. Unfortunately, UI5 still requires a browser for testing. The biggest issue is the UI5 AMD-like module system which doesn’t work in Nodejs runtime. Can we have ES modules in UI5, please? To solve this problem, we can use a javascript implementation of a web browser for Nodejs that implements web standards for DOM and HTML, but no real UI. Vitest has an experimental browser feature to test in a real browser, not GA yet, but I won’t use it to make a fair comparison.

The best Nodejs “web browser” options are jsdom and Happy DOM. In the next blogs, we’ll see how easy, simple and fast they are. We’re going to setup and run both at the same time for comparison. The main difference will be setup (which I prefer the jsdom approach). In a real project you only need one, pick the one that suits you best. Yes, the same approach could be used for Mocha, AVA and others…

Before somebody says something like “hey, there’s a node-qunit project that runs QUnit in Nodejs!”, I have to tell you it doesn’t work. It’s an abandoned project with the last commit made 3 years ago. It’s built with an ancient Nodejs version (v10), it doesn’t run on modern versions and it’s not meant to test web applications. But I tried. I forked the project and fixed it to run on v20, but still couldn’t make it load the UI5 files. I tried just because everybody uses QUnit in the UI5 community. TBH, I’m glad it didn’t work, I didn’t want to invest my time on dead tech…


A list of js test frameworks in chronological order – Best of JS


Another good option could be Web Test Runner, from Modern Web, which seems to be the Karma replacement (at least for Angular people). I haven’t explored it (yet) because I didn’t want another in-browser test, I wanted to run it in Nodejs.

In the next 3 blogs, 1 for each test library, we’ll see how to configure these test libraries, jsdom and Happy DOM. Then, we’ll run the tests and check the results. After playing around with the options, let me know which one is your favorite.


Edit: I’ve added more reasons explaining why I’m doing it this way…

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Volker Buzek
      Volker Buzek

      grrreat! And I‘m assuming you‘re aiming for the Unit-/Integration-Test scope. But pretty please 😀 can you also take wdi5 into account?


      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer
      Blog Post Author

      I'm focusing on unit test for now. However, the same approach could be used for integration tests.

      The problem is: I believe my views on Fiori/UI5 integration tests are far away from what the community believes and practices.

      Not considering wdi5 for 2 reasons: it's browser based and it's UI5 only.

      Author's profile photo Volker Buzek
      Volker Buzek

      understanding your sentiment, yet: aren't you explicitly using Jest etc for demoing UI5 testing?!

      plus: wdi5 lives in Node.js, remote-controlling the browser - not browser based 😉

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer
      Blog Post Author

      Do you have the option to test UI5 code in wdi5 without a browser? No. Meaning, the test is browser-based.

      When you run wdi5, your UI5 code is executed in the browser context, not in the nodejs context. There's no intersection, it's another process, perhaps even another node:vm (I haven't checked the code to be sure).

      The nodejs runtime doesn't have direct access to any variable available in the browser context, eg, window or sap or jQuery globals. You must use browser.execute to access whatever you want inside the browser context and return to the nodejs one.

      We could have a wdi5 version written in ABAP, if it executes the UI5 code inside a browser, it's a browser-based test. I don't make the rules 😜

      Author's profile photo Volker Buzek
      Volker Buzek

      Fair enough. However, one could argue what browser-based means. UI5 is a browser-scoped framework and is not intended to run in Node. So why force-transfer it? And using DOM-"emulators" such as jsdom to run tests is problematic in itself, as it is different from how "real" browsers handle the DOM.

      But anyway, the idea you showcase is clear: making modern test runners work with UI5! It is a good initiative  to look beyond the current boundaries of qUnit and karma 👍 Hope Chieftain Peter Muessig is listening 🙂

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer
      Blog Post Author

      Sure one could argue that. One'll always argue over anything. That's why the internet exists 😅

      It's all about options and testing strategy. Unit testing doesn't replace a proper integration or e2e tests. Combining them get you covered.

      React, Vue, Svelte... All modern, and most used, js frameworks use the same approach for unit test. The weekly download numbers behind nodejs browser-like options are insane! I'm not the only one using it for a browser-scoped framework...

      jsdom: 21M

      happy-dom: 316K

      qunit: 179K

      @ui5/cli (the most downloaded package in the ui5-verse): 66K

      @testing-library has another millions of weekly downloads for all its flavors.

      Should we try the same with UI5? Should we give options to the community? Does it have to be 1 option only? Lightweight, light-speed, and low/no configuration (not at UI5 for now) are good reasons to use it.

      Author's profile photo Simon Coen
      Simon Coen

      Great blog post about an important topic! Looking forward for the next ones.

      One thing that is maybe missing here, is that you are only tackling the unit-test layer, right?

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer
      Blog Post Author

      That's correct, it's unit test. See my reply to Volker 🙂

      Author's profile photo m d
      m d

      what Can i demo ERP in SAP

      Author's profile photo Arnaud Buchholz
      Arnaud Buchholz

      Did you have a look to ui5-test-runner ( ?

      I am also a big fan of Jest / vitest but I also do like the way qUnit and OPA are well integrated inside UI5. Furthermore, the fact that you can run the tests in a browser is quite helpful when it comes to debugging.

      ui5-test-runner aims to replace karma with some benefits : faster, better reporting and it can now run tests from self hosted applications (like the samples one on the UI5 website).

      Author's profile photo Mauricio Lauffer
      Mauricio Lauffer
      Blog Post Author

      Hi Arnaud, yep, I've seen it before. I love OPA concept, but I'm not a big fan of qUnit 😅. You can also debug when running in nodejs only.