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.
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).
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.
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.
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…
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...
- Overview
- Jest
- Vitest
- Node Test Runner
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 - https://jestjs.io
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 - https://vitest.dev
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 - https://nodejs.org/api/test.html
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...
- SAP Managed Tags:
11 Comments
