Jest vs. Vitest: Welches Framework ist für SPFx besser geeignet?
Überblick Test Frameworks Jest und Vitest
In diesem Blogpost beschäftige ich mich mit den Testframeworks Jest [1] und Vitest [2] im Zusammenhang mit dem SharePoint-Framework (SPFx) [3] und der Frage, welches Testframework ist zurzeit für neue SPFx-Projekte besser geeignet?
Jest ist ein weit verbreitetes JavaScript Testframework, das vor allem für das Testen von Frontend Anwendungen (z. B. mit React, Vue oder Angular) sowie von Node.js Backends eingesetzt wird. Es wurde ursprünglich von Facebook entwickelt und wird heute als Open Source Projekt gepflegt. Das Projekt sagt von sich selbst:
„Jest ist ein hervorragendes JavaScript-Testframework, bei dem Einfachheit im Vordergrund steht.“
Vitest ist ein modernes, schnelles JavaScript Testframework für Unit-, Integrations- und Component-Tests. Es wurde speziell für Projekte entwickelt, die Vite [4] als Build-Tool nutzen, kann aber auch unabhängig davon eingesetzt werden. Das Projekt sagt von sich selbst:
„Vite ist ein blitzschnelles Frontend-Build-Tool für die nächste Generation von Webanwendungen.“
Überblick SharePoint-Framework
Das SharePoint Framework ist ein von Microsoft bereitgestelltes Entwicklungsframework, mit dem sich individuelle Erweiterungen und Anwendungen für SharePoint Online und Microsoft Teams erstellen lassen.
Mit dem Release der Version 1.22 des SharePoint-Frameworks hat Microsoft die vom Framework verwendete Toolchain von gulp auf heft umgestellt. Microsoft schreibt dazu:
„Heft ist eine konfigurationsgesteuerte Toolchain, die andere gängige Tools wie TypeScript, ESLint, Jest, Webpack und API Extractor nutzt, um Webanwendungen, Node.js-Dienste, Befehlszeilentools und Bibliotheken zu erstellen.“ [5].
Überblick Viva Connections
Microsoft Viva Connections ist ein Modul der Microsoft Viva Employee Experience Platform und dient als zentrale Kommunikations- und Informationsdrehscheibe für Mitarbeitende – direkt integriert in Microsoft Teams. Viva Connections bringt das Intranet auf Basis von Microsoft SharePoint nach Teams [6]. Microsoft sagt dazu:
„Fördern Sie Bindung und vereinfachen Sie Arbeit mit einer vollständig auf das Unternehmen zugeschnittenen App-Erfahrung.“
Projekt-Überblick
Wie von Microsoft proklamiert, werden im Rahmen der Einführung und Verwendung von Viva Connections eine Reihe von sog. adaptiven Karten [7] entwickelt. Dabei handelt es sich um SPFx Erweiterungen, die über ein Dashboard zugänglich gemacht werden. In manchen Fällen reicht bereits das deklarative JSON-Schema von Adaptive Cards [8], um sinnvolle und nützliche Karten anzuzeigen. Bei anspruchsvolleren Anwendungsfällen wird (in unserem Fall) auf das React Framework [9] zurückgegriffen. Der im Rahmen des Projekts entwickelte Code, also z. B. React Komponenten, muss selbstverständlich getestet werden. Dabei stellen sich u. a. die Fragen:
- Sollte für alle selbst entwickelten adaptiven Karten das gleiche Test Framework verwendet werden?
- Welche oder welches Test Framework(s) sollte(n) verwendet werden?
Verwendung eines einheitlichen Test Frameworks
Die Beantwortung der ersten Frage erscheint im ersten Moment recht einfach: klar, ein einheitliches Test Framework für alle beteiligten Projekte macht absolut Sinn! Schließlich vereinfacht dieser Ansatz die Arbeit im Team. Es muss nur eine Dokumentation angelegt werden. Es reicht, sich in ein Test Framework einzuarbeiten. Und erworbene Fähigkeiten können in jedem beteiligten Software-Projekt eingesetzt werden.
In meinem Blogpost beziehe ich mich zwar nur auf ein neu gestartetes Software-Projekt, aber es ist gut zu wissen, dass sich Jest Tests leicht (mit Hilfe von KI) in Vitest Tests umschreiben lassen. Auf diese Weise würden sich also bequem auch Tests bestehender Software-Projekte konvertieren lassen.
Jest oder Vitest?
Für die Beantwortung dieser Frage habe ich mir die folgenden Aspekte angeschaut:
- Welches Test Framework wird vermutlich von Microsoft selbst verwendet bzw. vom SharePoint Framework direkt unterstützt?
- Welches Test Framework lässt sich am einfachsten erlernen und verwenden?
- Welches Test Framework ist am verbreitetsten und wird vermutlich am ehesten in Zukunft fortbestehen?
- Welches Test Framework ist am schnellsten?
Test Framework Jest ist bereits integriert
In den Release Notes von SPFx v1.22 [10] erwähnt Microsoft die Umstellung auf die heft-basierte Toolchain. Auf der Erklärungsseite zu der neuen Toolchain findet sich dann u.a. auch ein Hinweis auf Jest.
„What makes Heft unique is its focus on optimization and completeness—it tracks fine-grained performance metrics, implements sophisticated optimizations like incremental compilation and filesystem caching, and provides a unified compiler pass for Jest, Webpack, and ESLint.“
Ich interpretiere das als Hinweis von Microsoft, welche Tools dort für die Entwicklung von SharePoint-Framework Lösungen verwendet werden. Bestätigt wird das bei der Erstellung neuer SharePoint-Lösungsprojekte mit dem Yeoman-Generator für SharePoint-Framework [11]. Denn der installiert und konfiguriert mit @rushstack/heft den oben erwähnten Stack aus Jest, Webpack und ESLint. Deshalb kommt schon ein leeres HelloWorld Projekt mit diesen Tools:
> heft test --clean --production
---- build started ----
[build:set-browserslist-ignore-old-data-env-var] Setting environment variable BROWSERSLIST_IGNORE_OLD_DATA=1
[build:copy-javascript] Copied 2 files and linked 0 files
[build:sass] Generating sass typings...
[build:sass] Generated sass typings
[build:typescript] Using TypeScript version 5.8.3
[build:typescript] Copied 6 files and linked 0 files
[build:lint] Using ESLint version 8.57.1
[build:webpack] Using Webpack version 5.95.0
[build:webpack] Running Webpack compilation
---- build finished (167.769s) ----
---- test started ----
[test:jest] Using Jest version 29.5.0
No tests found, exiting with code 0
[test:jest]
[test:jest] Run start. 0 test suites
[test:jest]
[test:jest] Tests finished:
[test:jest] Successes: 0
[test:jest] Failures: 0
[test:jest] Total: 0
---- test finished (25.636s) ----
-------------------- Finished (193.422s) --------------------Ich nehme an, für Entwickler eigener SharePoint-Framework Lösungen ist es deshalb von Vorteil, auch diesen Stack einzusetzen.
Dies ist der Quellcode eines Jest Tests:
/// <reference types='jest' />
import { getDistanceBetweenTwoCoordinates as getDBTC } from '../services/GeoLocationService';
describe('GeoLocationService', () => {
it.each<locations>([
[48.98114512370473, 8.410918792287209, 48.98114512370473, 8.410918792287209, 0],
[48.98114512370473, 8.410918792287209, 48.980915353718714, 8.403723974331333, 526]
])('getDBTC should return %i', (lat1: number, long1: number, lat2: number, long2: number, dist: number) => {
expect(getDBTC(lat1, long1, lat2, long2)).toBe(dist);
});
});In einem produktiven SPFx Projekt habe ich 99 Testfälle in 7 Test-Suiten erstellt und die Dauer aller Tests bei einem „Kaltstart“ gemessen:
> Measure-Command { heft test --clean --production }
Days : 0
Hours : 0
Minutes : 0
Seconds : 12
Milliseconds : 33
Ticks : 120330498
TotalDays : 0,000139271409722222
TotalHours : 0,00334251383333333
TotalMinutes : 0,20055083
TotalSeconds : 12,0330498
TotalMilliseconds : 12033,0498
[test:jest] Run start. 7 test suites
[test:jest] Successes: 99
[test:jest] Failures: 0
[test:jest] Total: 99
--------------------------------------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
--------------------------------------|---------|----------|---------|---------|-------------------
All files | 66.71 | 85.48 | 91.17 | 66.71 |
myApprovals | 0 | 0 | 0 | 0 |
MyApprovalsAdaptiveCardExtension.ts | 0 | 0 | 0 | 0 | 1-299
MyApprovalsPropertyPane.ts | 0 | 0 | 0 | 0 | 1-130
myApprovals/cardView | 100 | 100 | 100 | 100 |
CardView.ts | 100 | 100 | 100 | 100 |
myApprovals/models | 100 | 100 | 100 | 100 |
ApprovalModel.ts | 100 | 100 | 100 | 100 |
myApprovals/quickView | 97.43 | 100 | 75 | 97.43 |
QuickView.ts | 97.43 | 100 | 75 | 97.43 | 57-58
myApprovals/services | 100 | 84 | 100 | 100 |
xxxxxxxxService.ts | 100 | 79.16 | 100 | 100 | 45,56,71
IApprovalService.ts | 100 | 100 | 100 | 100 |
xxxxxxxxxxxxxxService.ts | 100 | 87.5 | 100 | 100 | 63,65
xxxxxxxxService.ts | 100 | 90 | 100 | 100 | 60-61
xxxxService.ts | 100 | 83.33 | 100 | 100 | 53
xxxxxxxxxxxxxxx Service.ts | 100 | 80 | 100 | 100 | 46,60,85-87
--------------------------------------|---------|----------|---------|---------|-------------------Man sieht also, Jest hat für die Ausführung aller 99 Testfälle 12,0330498 Sekunden benötigt. Bei weiteren Durchläufen variiert die Dauer zwischen 10 und 13 Sekunden.
Die Codeabdeckung wurde mit V8 [12] berechnet, der Standard-Einstellung bei SPFx v1.22. Die nachfolgende Abbildung zeigt beispielhaft die Codeabdeckung des Approval Service Interface mit 28 von 28 Statements.
Abschließend werfe ich noch einen schnellen Blick auf das Jest Projekt allgemein:
- 3k stars
- 551 watching
- 6k forks
- 1,590 contributors
- 41,875,695 weekly downloads at npm
Test Framework Vitest ist schneller
Die Umstellung von Jest auf Vitest ist – auch mittels KI – schnell und unkompliziert. Microsofts SPFx-Team hat zu dem Thema kürzlich einen Post samt GitHub Prompt veröffentlicht [13]. Mit dem darin erwähnten Prompt lässt sich ein bestehendes SPFx Projekt mit Jest ganz einfach umkonfigurieren zu Vitest. Auf ähnliche Weise habe für diesen Blogpost die Jest Tests in meinem Beispielprojekt umgewandelt in Vitest Tests. Der zuvor erwähnte GitHub Prompt aktualisiert auch die package.json und ändert darin die Script-Anweisung. Der Befehl, um die Tests auszuführen lautet bei Vitest:
> npm test
> sharepoint-viva-connections@4.5.3 test
> vitest run --coverage
RUN v2.1.9 C:/xxx/sharepoint-viva-connections
Coverage enabled with v8
% Coverage report from v8
=============================== Coverage summary ===============================
Statements : 0% ( 0/299 )
Branches : 0% ( 0/14 )
Functions : 0% ( 0/14 )
Lines : 0% ( 0/299 )
================================================================================
include: src/**/*.test.{ts,tsx}
exclude: **/node_modules/**, **/lib/**, **/lib-commonjs/**, **/dist/**
No test files found, exiting with code 1Mit den Befehlen describe, it und expect implementiert man Vitest Tests sehr ähnlich wie Jest Tests. Der zuvor gezeigte Beispiel-Test für Vitest sieht so aus:
import { describe, it, expect } from 'vitest';
import { getDistanceBetweenTwoCoordinates as getDBTC } from '@src/adaptiveCardExtensions/helloWorld/services/GeoLocationService';
describe('GeoLocationService', () => {
it.each([
[48.98114512370473, 8.410918792287209, 48.98114512370473, 8.410918792287209, 0],
[48.98114512370473, 8.410918792287209, 48.980915353718714, 8.403723974331333, 526]
])('getDBTC should return %i', (lat1: number, long1: number, lat2: number, long2: number, dist: number) => {
const distance = getDBTC(lat1, long1, lat2, long2);
expect(distance).toBe (dist);
});
});Zu Testzwecken (lol) habe ich die 99 Testfälle des oben erwähnten produktiven SPFx Projekts umschreiben lassen in Vitest Tests. Die Zeitmessung ergab:
> Measure-Command { npm test }
Days : 0
Hours : 0
Minutes : 0
Seconds : 3
Milliseconds : 308
Ticks : 33083996
TotalDays : 3,8291662037037E-05
TotalHours : 0,000918999888888889
TotalMinutes : 0,0551399933333333
TotalSeconds : 3,3083996
TotalMilliseconds : 3308,3996
Test Files 7 passed (7)
Tests 99 passed (99)
Start at 10:13:57
Duration 2.36s
=============================== Coverage summary ===============================
Statements : 58.81% ( 397/675 )
Branches : 97.77% ( 88/90 )
Functions : 90.62% ( 29/32 )
Lines : 58.81% ( 397/675 )
================================================================================Die Ausführung aller 99 Testfälle beim “Kaltstart“ mit Vitest dauerte also nur 3,08 Sekunden. Das Vitest-Team behauptet also zurecht „A Vite-native testing framework. It's fast!“
Vitest verwendet ebenfalls V8 für die Berechnung der Codeabdeckung, allerdings wird der TypeScript Code nicht zuvor in CommonJS transformiert. Die Anzahl der Statements im zuvor bereits untersuchten Approval Service Interface fällt deshalb mit 9 von 9 Statements geringer aus.
Auch bei Vitest noch ein schneller allgemeiner Blick auf das Projekt:
- 4k stars
- 53 watching
- 7k forks
- 733 contributors
- 57,086,162 weekly downloads at npm
Zusammenfassung Jest vs. Vitest
Als ich diesen Blogpost zu Schreiben begonnen habe, war ich der festen Überzeugung mit Jest bereits das geeignetste Testframework einzusetzen. Doch wenn ich mir jetzt, am Ende dieses Blogposts wieder die Frage stelle: „Welches Testframework ist zur Zeit für neue SPFx-Projekte besser geeignet?“, dann tendiert meine Antwort zu Vitest! Und das sind die Gründe für meine Entscheidung:
- Der Geschwindigkeitsvorteil von Vitest gegenüber Jest ist enorm
- Mit KI gibt es einen geeigneten und bereitwilligen Helfer, wenn es um die Konvertierung bestehender Jest Tests in Vitest Tests geht
- Mit dem GitHub Copilot Prompt des SPFx-Teams gibt es eine funktionierende Lösung für die Konvertierung von Jest nach Vitest
- Die Community Analytics, speziell die weekly downloads geben einen Hinweis, welches Testframework aufstrebender ist
- Einzelne Kommentare in Diskussionen auf GitHub deuten ebenfalls einen bestimmten Trend an, z. B. "Jest is no longer the clear industry default. Vitest is rapidly gaining ground and is the preferred choice for new projects across the ecosystem." [14]
Zugabe
Und weil zur Zeit alles mit KI sein muss, hier noch die Antwort von Microsoft Copilot auf die zuvor gestellte Frage. Copilot antwortet: "Kurzfassung vorab: Für neue SPFx‑Projekte ist Jest aktuell die beste Wahl für Unit- und Komponententests, kombiniert mit Playwright für End‑to‑End‑Tests.".
Naja, auf der Copilot-Seite steht ja auch unten ganz klein "KI-generierte Inhalte können fehlerhaft sein". 😁
Links
[1] Jest - Delightful JavaScript Testing
[2] Vitest | Next Generation Testing Framework
[3] Overview of the SharePoint Framework
[4] Vite | Next Generation Frontend Tooling
[5] SharePoint Framework Toolchain: Heft & Webpack
[6] Microsoft Viva Connections
[7] Adaptive Cards
[8] JSON-Schema von Adaptive Cards
[9] React
[10] SharePoint Framework v1.22 release notes
[11] Yeoman generator for the SharePoint Framework
[12] V8 JavaScript Engine
[13] Level up SharePoint SPFx Projects with Vitest Unit Testing
[14] @microsoft/spfx-web-build-rig unnecessarily generates lib-commonjs folder in SPFx projects
