NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Kung Fu Meister in gelbem Anzug korrigiert Roboter mit StrykerJS Testblatt

Was ist StrykerJS

StrykerJS ist ein Open Source Framework für Mutation Testing in JavaScript und TypeScript. Es verändert euren Produktivcode an vielen kleinen Stellen, führt nach jeder Änderung eure Tests aus und misst, wie viele dieser Änderungen die Tests bemerken.
Jede eingebaute Änderung heißt Mutant. Killt eure Testsuite den Mutanten, ist der Test scharf. Überlebt der Mutant, habt ihr eine Zeile, die zwar ausgeführt, aber nicht wirklich geprüft wird. Genau diese Lücke findet Code Coverage nie: Coverage sagt diese Zeile lief, der Mutation Score sagt ein Fehler in dieser Zeile wäre aufgefallen.
Das Projekt läuft unter Apache 2.0 Lizenz im Monorepo stryker-mutator/stryker-js. Aktuell ist Version 10.0.0 vom 14. August 2026. Sie setzt Node.js 22 oder höher voraus. StrykerJS ist der JavaScript Ableger der Stryker Familie, zu der auch Stryker.NET für C Sharp und Stryker4s für Scala gehören.

Inhalt

StrykerJS mit NCA: Schnelle Hilfe vom Experten

Never Code Alone kommt aus der Testing Ecke. Roland Golla arbeitet seit über 20 Jahren an Softwarequalität, ist Cypress Ambassador und hat Codeception Tests zum TYPO3 Core beigetragen. Mutation Testing ist bei uns kein Vortragsthema, sondern Teil der Quality Gates: im PHP Stack mit PHPUnit, PHPStan und Rector, im Frontend mit TypeScript, Vitest und Cypress. Wir wissen deshalb, wo ein Mutation Score ehrlich weh tut und wo er nur CI Zeit verbrennt.
Wir bringen Testqualität dort hin, wo sie gebraucht wird. Im Codebase Audit für KI generierten Code prüfen wir bestehende Testsuiten auf genau solche blinden Flecken. In den Vibe Coding CI CD Pipelines und bei Quality Gates für KI Code verankern wir die Schwellen so, dass sie Builds nicht blockieren, sondern führen. Für Teams, die den Einstieg in KI gestützte Entwicklung sauber aufsetzen wollen, gibt es das Vibe Coding Consulting, die Vibe Coding Best Practices und unsere Agentic AI Coding Guardrails für bestehende Projekte.
Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

So funktioniert Mutation Testing in der Praxis

Ein kleines Beispiel zeigt das Prinzip schneller als jede Definition. Diese Funktion prüft einen Preis:
Code: 
          
export function isValidPrice(price) {
  return price > 0;
}
Dazu gibt es einen Test, der auf den ersten Blick sauber aussieht und 100 Prozent Coverage liefert:
Code: 
          
import { expect, it } from 'vitest';
import { isValidPrice } from './price.js';

it('erkennt einen gueltigen Preis', () => {
  expect(isValidPrice(10)).toBe(true);
  expect(isValidPrice(-5)).toBe(false);
});
StrykerJS baut jetzt Mutanten ein. Einer davon ersetzt den Vergleich durch price >= 0. Der Test läuft weiterhin grün, denn der Grenzfall price gleich 0 wird nie geprüft. Der Mutant überlebt und markiert die Lücke, die die Coverage Zahl verschwiegen hat.
Das Ergebnis ist der Mutation Score: der Anteil getöteter Mutanten an allen erzeugten Mutanten. Eingebaute Mutatoren decken Vergleichsoperatoren, Rechenoperatoren, Boolean Rückgaben, String Literale, Arrays, Optional Chaining und reguläre Ausdrücke ab. Reguläre Ausdrücke mutiert die Bibliothek Weapon regeX, die auch Stryker4s nutzt.
Mutanten, die sich nicht töten lassen, weil der mutierte Code identisch funktioniert, heißen äquivalente Mutanten. StrykerJS bietet drei Wege, sie loszuwerden: den Mutator komplett abschalten über mutator.excludedMutations, einen Kommentar Stryker disable direkt im Code oder ein Ignore Plugin für wiederkehrende Muster. Ignorierte Mutanten bleiben im Report, drücken aber nicht mehr auf den Score.

StrykerJS installieren und den ersten Lauf starten

Der Einstieg dauert wenige Minuten. Wechselt ins Projektverzeichnis und startet den Initializer. Er fragt Test Runner, Reporter und Konfigurationsformat ab und legt die Konfiguration an:
Code: 
          
cd mein-projekt
npm init stryker@latest
Danach startet der erste Durchlauf:
Code: 
          
npx stryker run
Wer die Pakete lieber selbst setzt, installiert Core, Runner und Checker direkt. Für ein TypeScript Projekt mit Vitest sieht das so aus:
Code: 
          
npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner @stryker-mutator/typescript-checker
Die Konfiguration liegt je nach Auswahl als stryker.config.json oder stryker.config.mjs im Projekt. Eine brauchbare Startkonfiguration für Astro, React oder Vue Projekte mit TypeScript:
Code: 
          
{
  "$schema": "./node_modules/@stryker-mutator/core/schema/stryker-schema.json",
  "testRunner": "vitest",
  "mutate": ["src/**/*.ts", "!src/**/*.spec.ts", "!src/**/*.test.ts"],
  "checkers": ["typescript"],
  "tsconfigFile": "tsconfig.json",
  "reporters": ["progress", "clear-text", "html"],
  "concurrency": "50%",
  "thresholds": {
    "high": 80,
    "low": 60,
    "break": 60
  }
}
Drei Stellen lohnen den zweiten Blick. Der TypeScript Checker wirft Mutanten weg, die gar nicht kompilieren würden, und spart damit Laufzeit statt sie zu verbrennen. Die Schwelle break lässt den Lauf scheitern, sobald der Score darunter fällt, und macht aus der Zahl ein echtes Quality Gate. Und mutate gehört auf Produktivcode beschränkt, niemals auf Testdateien.
Neben Vitest unterstützt StrykerJS Jest, Mocha, Jasmine, Karma, CucumberJS und den Test Runner von Node.js über den Tap Runner. Für Angular, React, Vue, Svelte und reine Node Projekte gibt es fertige Guides in der offiziellen Dokumentation. Wie Vitest selbst aufgesetzt wird, steht in unserem Artikel zu Vitest und schnellem JavaScript Testing, die Basis dafür liefert der TypeScript strict Mode.

Neu in StrykerJS 10: das bringt das Release vom August 2026

Version 10.0.0 ist am 14. August 2026 erschienen. Der Sprung auf die neue Hauptversion hat genau einen Breaking Change, der Rest sind Features. Wer von 9.x kommt, prüft zuerst die Node Version.
Node.js 22 ist Pflicht. Der Support für Node.js 20 ist raus. Das ist der einzige Breaking Change im Release und meist eine Sache der CI Konfiguration, nicht des Codes.
Experimenteller TypeScript 7 Support. Der typescript-checker kommt mit der in Go geschriebenen neuen Compiler Generation zurecht. Für Teams, die den nativen Compiler schon testen, fällt damit ein Blocker weg.
Neuer empty-expression-mutator. Ausdrücke werden durch einen leeren Ausdruck ersetzt. Das trifft Code, der aufgerufen wird, ohne dass sein Ergebnis je geprüft wird, und findet damit eine bisher schlecht abgedeckte Klasse von Lücken.
Mutant Filtering. Mutanten lassen sich gezielter auswählen, statt immer den kompletten Satz zu erzeugen. Zusammen mit dem inkrementellen Modus ist das der Hebel für kurze Feedbackzeiten in großen Codebasen.
Teil Report bei Abbruch. Bricht ein Lauf unerwartet ab, schreibt StrykerJS den bis dahin erreichten inkrementellen Report trotzdem weg. Ein abgeschossener CI Job wirft die Arbeit damit nicht mehr komplett weg.
Dazu kommen Babel 8 als Parser Basis, Unterstützung für Mocha 12, sauberes Parsen von TypeScript in Svelte Templates und deutlich weniger Warnungsrauschen im Vitest Runner.

StrykerJS Releases im Überblick

Version Datum Wichtigste Neuerung
10.0.0 14. August 2026 Node.js 22 Pflicht, TypeScript 7 experimentell, empty-expression-mutator, Mutant Filtering
9.6.0 27. Februar 2026 Concurrency als Prozentwert der CPU Kerne konfigurierbar
9.5.0 30. Januar 2026 Option testFiles grenzt die laufenden Tests ein, Vitest Fixtures werden unterstützt
9.4.0 23. November 2025 Unterstützung für Vitest 4
9.1.0 30. August 2025 Mutation Server Protocol als Basis für das VS Code Plugin

Mutation Testing direkt in der IDE

Die spannendste Entwicklung der letzten Releases steckt nicht im Mutator, sondern im Protokoll. Seit Version 9.1 spricht StrykerJS das Mutation Server Protocol. Der Gedanke dahinter ist derselbe wie beim Language Server Protocol: Ein Editor redet über eine standardisierte Schnittstelle mit dem Werkzeug, statt für jedes Tool eine eigene Integration zu bauen. Seit 9.3 läuft die Verbindung auch über stdio.
Darauf setzt das offizielle VS Code Plugin auf, das im November 2025 erschienen ist. Es hängt sich in den Test Explorer, zeigt Mutanten pro Datei oder Ordner und blendet direkt im Editor ein, welche Mutation überlebt hat und wie der veränderte Code aussieht. Der Umweg über Terminal und HTML Report entfällt. Vorausgesetzt wird StrykerJS ab 9.3.0.
Für die Praxis ändert das die Reihenfolge. Mutation Testing war lange ein Batch Job, dessen Ergebnis man am nächsten Morgen im Report gelesen hat. Jetzt ist es ein Werkzeug, das beim Schreiben eines Tests direkt Auskunft gibt. Wer Tests als lebende Spezifikation versteht, bekommt damit endlich das passende Feedback im richtigen Moment.

Warum Mutation Testing bei KI generiertem Code wichtiger wird

KI Agenten schreiben schnell Tests. Sie schreiben sie auch gern so, dass die Zahlen gut aussehen. Ein Agent, der auf Coverage optimiert, produziert Tests, die jede Zeile anfassen und trotzdem kaum etwas behaupten: ein Aufruf, ein Snapshot, ein toBeDefined. Die Pipeline ist grün, die Metrik stimmt, die Schutzwirkung ist nahe null.
Mutation Testing ist gegen diesen Effekt immun, weil es die Testsuite selbst unter Druck setzt. Ein Test, der nichts prüft, killt keinen Mutanten. Der Score fällt sofort auf. Das macht StrykerJS zu einem der wenigen Werkzeuge, die die Qualität eines generierten Tests messen können, statt seine Existenz zu zählen.
In der Praxis heißt das: Coverage bleibt als billige Basismetrik in jedem Build, der Mutation Score kommt als Prüfung für die Module, an denen wirklich Geld hängt. Genau so bauen wir Quality Gates in automatisierten KI Code Reviews und im Vibe Coding Security Audit.
Der Reflex, den wir Teams austreiben, ist der umgekehrte: erst generieren, dann Tests nachreichen, dann hoffen. Wer mit Example Mapping und klaren Regeln in rules.md und AGENTS.md arbeitet, hat die Prüfkriterien vor dem Code. Mutation Testing bestätigt dann nur noch, dass die Tests halten, was die Spezifikation verspricht. Für Projekte, die diesen Schritt übersprungen haben, ist das AI Slop Refactoring der Weg zurück.

StrykerJS in CI: Laufzeit im Griff behalten

Mutation Testing ist teuer. Für jeden Mutanten läuft ein Teil der Testsuite erneut. Ein Projekt mit ein paar tausend Mutanten kommt ohne Vorkehrungen leicht auf Laufzeiten, die niemand in einem Pull Request abwartet. StrykerJS liefert dafür mehrere Stellschrauben.
Inkrementeller Modus. Mit dem Flag incremental vergleicht StrykerJS Code und Tests mit dem letzten Report und rechnet nur die geänderten Teile neu. Der Report am Ende ist trotzdem vollständig.
Code: 
          
npx stryker run --incremental
Coverage Analyse pro Test. Die Einstellung perTest sorgt dafür, dass pro Mutant nur die Tests laufen, die die betroffene Zeile überhaupt berühren. Das ist der größte einzelne Hebel und bei allen echten Test Runnern die Voreinstellung.
Parallelität. Seit Version 9.6 lässt sich die Anzahl der Worker als Prozentwert der verfügbaren Kerne angeben. Auf einem schwankenden CI Runner ist das robuster als eine feste Zahl.
Scope begrenzen. Nicht jedes Verzeichnis braucht einen Mutationslauf. Kritische Geschäftslogik ja, generierte Clients und Konfiguration nein. Ein guter Rhythmus ist: inkrementell bei jedem Push, voller Lauf nachts oder vor dem Release. Wie das in einer kompletten Pipeline aussieht, zeigen unsere Vibe Coding CI CD Pipelines.
Ein Wort zur Zielzahl: Ein Mutation Score von 80 Prozent gilt als guter Wert. Die 100 ist kein Ziel, sondern ein Zeitfresser. Die letzten Prozentpunkte bestehen meist aus äquivalenten Mutanten und Code, dessen Verhalten schlicht egal ist.

See which mutants survive or are killed without leaving your editor.

Nico Jansen, Stryker Team – Stryker Mutator Blog

Unsere Erfahrung mit Mutation Testing

Mutation Testing ist keine neue Mode. In der PHP Welt arbeiten wir seit Jahren mit dem Infection Framework, dem direkten Gegenstück zu StrykerJS. Das Prinzip ist identisch, nur die Sprache ist eine andere. Wer beide Stacks bedient, kann dieselbe Denkweise übertragen: erst Coverage als Hygiene, dann Mutation Score für die Module mit Risiko.
Im Frontend hängt StrykerJS an einer Kette, die sauber sein muss. Ohne TypeScript strict Mode und ohne belastbare Validierung wie mit Zod 4 erzeugt ein Mutationslauf vor allem Rauschen. Unsere AI Coding Guidelines für TypeScript Projekte beschreiben, wie diese Basis aussieht. Für die Oberfläche kommen bei uns Cypress E2E Tests dazu, für die Struktur Astro.
In der Beratung sehen wir denselben Fall immer wieder: Eine Testsuite mit hoher Coverage, die beim ersten Mutationslauf auf einen Score unter 50 fällt. Das ist kein Grund für schlechte Laune, sondern eine präzise Liste, wo Tests nachgeschärft gehören. Wie wir das aufarbeiten, steht im Codebase Audit, in den Quality Gates für KI Code und bei Exact Coding. Wer die Ursachen verstehen will, findet sie bei technischen Schulden durch Vibe Coding und bei agentischen Akzeptanztests.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Frontend 2025: Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile der Barrierefreiheit

Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile einer schnellen, sicheren und barrierefreien Webseite. Erfüllen Sie die gesetzlichen Anforderungen und verbessern Sie die Benutzererfahrung Ihrer Webseite. Mit Astro JS können Sie die Ladezeit reduzieren, die Sicherheit maximieren und die SEO-Optimierung verbessern. Kontaktieren Sie uns, um mehr zu erfahren und um Ihre Webseite auf ein neues Level zu heben.

Astro JS Frontend E-Mail Kontakt

Häufige Fragen zu StrykerJS

Die Fragen, die uns zu Mutation Testing im JavaScript Umfeld am häufigsten erreichen, mit kurzen Antworten aus der Praxis.

Welche StrykerJS Version ist 2026 aktuell?

Aktuell ist StrykerJS 10.0.0 vom 14. August 2026. Das Hauptpaket heißt @stryker-mutator/core, alle offiziellen Plugins tragen dieselbe Versionsnummer. Davor war 9.6.1 vom 10. April 2026 aktuell. Das Projekt folgt Semantic Versioning, ein Major Release pro Jahr ist die Regel und wird meist vom Ende des Supports einer Node Version ausgelöst.

Welche Node Version braucht StrykerJS 2026?

StrykerJS 10 setzt Node.js 22 oder höher voraus. Der Support für Node.js 20 ist mit dem August Release entfallen. Das ist der einzige Breaking Change der Version. Wer noch auf Node 20 arbeitet, bleibt vorerst auf der Linie 9.6.1 oder hebt zuerst die Node Version in CI und in der lokalen Umgebung an.

Was ist neu in StrykerJS 10 im Jahr 2026?

Neu sind der empty-expression-mutator, Mutant Filtering für gezieltere Läufe und experimenteller Support für TypeScript 7 im Checker. Bricht ein Lauf unerwartet ab, wird der bis dahin erreichte inkrementelle Report trotzdem gespeichert. Dazu kommen Babel 8, Unterstützung für Mocha 12 und weniger Warnungsrauschen im Vitest Runner.

Unterstützt StrykerJS 2026 Vitest 4?

Ja. Der Support für Vitest 4 kam mit Version 9.4.0 im November 2025, Fixtures über test.extend folgten in 9.5. Den Browser Mode unterstützt der Runner seit Version 9.0. Der Vitest Runner wird als eigenes Paket installiert und in der Konfiguration über testRunner ausgewählt.

Lohnt sich Mutation Testing 2026 bei KI generiertem Code?

Gerade dann. KI Agenten erzeugen leicht Tests, die jede Zeile berühren und trotzdem nichts behaupten. Coverage bewertet solche Tests positiv, Mutation Testing nicht: Ein Test ohne echte Zusicherung tötet keinen Mutanten und der Score fällt sofort. Das macht den Mutation Score zur ehrlichsten Metrik für generierte Testsuiten.

Was ist der Unterschied zwischen Code Coverage und Mutation Score?

Coverage misst, ob eine Zeile während der Tests ausgeführt wurde. Der Mutation Score misst, ob ein Fehler in dieser Zeile aufgefallen wäre. Eine Testsuite kann 100 Prozent Coverage haben und trotzdem keinen einzigen Grenzfall prüfen. Coverage ist eine Hygienemetrik, der Mutation Score eine Qualitätsaussage.

Wie hoch sollte der Mutation Score sein?

Ein Wert ab 80 Prozent gilt als gut. Die 100 ist kein sinnvolles Ziel, weil die letzten Punkte fast immer aus äquivalenten Mutanten und aus Code bestehen, dessen Verhalten egal ist. Sinnvoller ist eine break Schwelle in der Konfiguration, die den Lauf scheitern lässt, sobald der Score unter einen vereinbarten Wert fällt.

Wie lange dauert ein Mutationslauf?

Deutlich länger als die Testsuite selbst, denn für jeden Mutanten laufen Tests erneut. Drei Hebel senken die Zeit: Coverage Analyse pro Test, sodass nur relevante Tests laufen, der inkrementelle Modus, der nur Geändertes neu rechnet, und eine passende Parallelität. Seit Version 9.6 lässt sich die Worker Anzahl als Prozentwert der CPU Kerne setzen.

Was sind äquivalente Mutanten?

Das sind Mutanten, deren veränderter Code sich exakt wie das Original verhält. Sie lassen sich prinzipiell nicht töten und drücken den Score unverdient. StrykerJS bietet drei Auswege: den Mutator über excludedMutations abschalten, einen Kommentar Stryker disable an die Stelle setzen oder ein Ignore Plugin für wiederkehrende Muster schreiben. Ignorierte Mutanten bleiben im Report sichtbar.

Funktioniert StrykerJS mit Jest?

Ja. Neben Vitest gibt es offizielle Runner für Jest, Mocha, Jasmine, Karma, CucumberJS und den Test Runner von Node.js über den Tap Runner. Die Wahl steht in der Konfiguration unter testRunner, das passende Plugin wird als Dev Dependency installiert. Für Angular, React, Vue, Svelte und Node gibt es eigene Setup Guides.

Kann ich Mutation Testing in VS Code nutzen?

Ja. Seit November 2025 gibt es ein offizielles Plugin für Visual Studio Code. Es zeigt Mutanten im Test Explorer, blendet überlebende Mutationen direkt im Editor ein und zeigt den veränderten Code als Diff. Voraussetzung ist StrykerJS ab Version 9.3.0. Technische Basis ist das Mutation Server Protocol, das seit 9.1 implementiert ist.

Gibt es Mutation Testing auch für PHP oder andere Sprachen?

Ja. Für PHP ist Infection das verbreitete Framework, für C Sharp gibt es Stryker.NET und für Scala Stryker4s, beide aus derselben Projektfamilie wie StrykerJS. Für Java ist PIT der Standard. Das Konzept ist überall identisch, nur Mutatoren und Konfiguration unterscheiden sich.

Wie binde ich StrykerJS in eine CI Pipeline ein?

Als eigener Job neben Unit Tests und statischer Analyse, nicht als Teil des normalen Testlaufs. Bewährt hat sich ein inkrementeller Lauf bei jedem Push und ein vollständiger Lauf nachts oder vor dem Release. Der HTML Report wird als Artefakt abgelegt, die break Schwelle entscheidet über Erfolg oder Abbruch des Jobs.