Das NCA TESTIFY Cypress Plugin ist ein Open Source Plugin, das fertige Tests für jede Website mitbringt. Mit einem einzigen Command prüfst du, ob alle internen Links funktionieren, alle Bilder laden und die Seite barrierearm ist.
Das Plugin heißt auf npm cypress-ncatestify-plugin und steht unter MIT Lizenz. Entwickelt und gepflegt wird es von Never Code Alone, der Code liegt öffentlich auf GitHub. Es läuft mit Cypress 15 und Node.js 22 oder neuer.
Die Idee dahinter ist einfach. Viele Checks sind auf jeder Website gleich: kaputte Links, fehlende Bilder, zwei H1 Überschriften, Links ohne HTTPS. Diese Tests schreibt kein Team gern jedes Mal neu. Das Plugin liefert sie fertig, du rufst sie nur noch auf.
Wir haben das Plugin selbst gebaut, weil wir dieselben Checks in jedem Projekt brauchten. Kaputte Links, fehlende Bilder, Google Fonts nach einem Theme Update: Das haben wir lange in jedem Projekt neu geschrieben. Heute ist es eine Zeile im CI/CD Setup. Cypress läuft bei uns mit Cypress Cloud täglich in Production, in Pipelines mit GitHub Actions und GitLab CI, und die Commands aus NCA TESTIFY laufen dort mit. Roland Golla ist offizieller Cypress Ambassador und arbeitet seit über 20 Jahren an Testing und Refactoring.
Wir richten das Plugin gemeinsam mit dir ein, im Cypress Workshop mit Roland Golla oder in den Cypress Power Hours. Für ganze Teams gibt es die Cypress Remote Schulung für Teams. In der Pipeline hängen wir die Checks als Quality Gates für KI Code ein, auf Basis eines sauberen CI/CD Pipeline Setup. Den Rahmen für Teams mit KI Agenten setzen die NCA Agentic AI Coding Guardrails.
Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.
Du brauchst ein Projekt mit Cypress. Dann sind es vier kurze Schritte. Zuerst installierst du das Plugin als Dev Abhängigkeit.
npm install cypress-ncatestify-plugin --save-dev
Danach importierst du das Plugin in deiner Support Datei, meist cypress/support/e2e.ts. Damit sind alle Commands registriert.
import 'cypress-ncatestify-plugin'
Das Plugin braucht eine baseUrl. Daran erkennt es, welche Links intern sind und welche nicht. Du setzt sie in der cypress.config.ts.
import { defineConfig } from 'cypress'
export default defineConfig({
e2e: {
baseUrl: 'https://deine-website.de'
}
})
Jetzt schreibst du den ersten Test. Jeder Check ist ein eigener Command mit dem Präfix tt, kurz für TESTIFY.
describe('Website Basis Checks', () => {
beforeEach(() => {
cy.visit('/')
})
it('alle internen Links liefern Status 200', () => {
cy.ttEveryInternalLinkStatusOk()
})
it('alle Bilder laden', () => {
cy.ttValidateAllImagesResponseStatusOk()
})
it('Seite ist barrierearm', () => {
cy.ttAccessibility()
})
})
Mit npx cypress open startest du den Test Runner und siehst jeden Schritt live. Für ttAccessibility brauchst du zusätzlich cypress-axe und axe-core, beide sind Peer Dependencies des Plugins.
Du willst nicht jeden Check einzeln aufrufen? Dann nimm ttValidatePageContent. Der Command bündelt die wichtigsten Prüfungen in einem Aufruf.
it('Basis Checks der Startseite', () => {
cy.visit('/')
cy.ttValidatePageContent()
})
Dahinter laufen nacheinander:
Das ist ein guter Startpunkt für jede neue Testsuite. Danach ergänzt du Tests für das, was nur deine Anwendung kann: Login, Checkout, Suche oder Formulare.
Cypress zeigt im Log die Selektoren an. Bei generierten IDs wie #ext-comp-1234 weiß niemand mehr, welches Element gemeint ist. cy.ttEl gibt jedem Element einen sprechenden Namen, der im Log erscheint.
cy.ttEl('#ext-comp-1234', 'usernameInput')
cy.ttEl('.btn-primary', 'submitButton')
Für größere Projekte bringt das Plugin eine BasePage Klasse für das Page Object Pattern mit. Der Name des Getters wird automatisch zum Namen im Log. Du musst ihn also nicht doppelt pflegen.
import { BasePage } from 'cypress-ncatestify-plugin'
export class LoginPage extends BasePage {
get usernameInput() {
return this.el('#username')
}
get passwordInput() {
return this.el('#password')
}
get submitButton() {
return this.el('button[type="submit"]')
}
login(user: string, pass: string) {
this.usernameInput.type(user)
this.passwordInput.type(pass)
this.submitButton.click()
}
}
Ändert sich ein Selektor, passt du ihn an genau einer Stelle an. Die Tests selbst lesen sich wie eine Beschreibung: loginPage.login(user, pass). Das hilft auch, wenn KI Agenten Tests schreiben oder reparieren, weil die Struktur klar vorgegeben ist.
Zwei Checks im Plugin gehen über klassisches Testing hinaus. Sie prüfen Themen, die in Deutschland rechtlich relevant sind.
ttValidateNoGoogleServices lädt die Seite neu und beobachtet alle externen Requests. Taucht ein Aufruf zu Google Fonts oder Google Maps auf, schlägt der Test fehl. So merkst du sofort, wenn ein Theme Update oder ein neues Plugin wieder Schriften von Google Servern nachlädt.
ttAccessibility nutzt cypress-axe und axe-core. Der Check findet fehlende Alternativtexte, schwache Kontraste und falsche ARIA Attribute bei jedem Testlauf. Das ist eine gute Grundlage für das Barrierefreiheitsstärkungsgesetz, ersetzt aber keine manuelle Prüfung. Welche Werkzeuge es daneben gibt, zeigen die Accessibility Testing Tools.
Eine Startseite allein sagt wenig. ttValidateSubpagesAndImages besucht verlinkte Unterseiten, scrollt jede Seite schrittweise nach unten und prüft danach alle Bilder. So werden auch Bilder mit Lazy Loading geladen und geprüft. Anzahl der Seiten, Link Selektor und Wartezeit kannst du anpassen.
cy.ttValidateSubpagesAndImages()
cy.ttValidateSubpagesAndImages(50, '[data-qa="article-link"]', 15000)
cy.ttEveryInternalLinkIsLoading(20, ['/logout'])
Das zweite Argument bei den Link Commands ist eine Ausschlussliste. Jeder Link, der einen dieser Texte enthält, wird übersprungen. Typische Kandidaten sind Logout Links oder Downloads. Links mit mailto, tel und javascript sowie externe Links filtert das Plugin selbst heraus.
Für geschützte Staging Umgebungen trägst du Benutzer und Passwort direkt in die baseUrl ein. Das Plugin reicht die Zugangsdaten an alle internen Requests weiter. In der Pipeline setzt du die URL als Umgebungsvariable, so landen keine Zugangsdaten im Repository.
export CYPRESS_BASE_URL=https://user:passwort@staging.example.com
npx cypress run
Die Basis Checks lesen nur und ändern keine Daten. Mit Cypress Grep taggst du sie als @readonly und lässt sie so auch gegen Production laufen, während schreibende Tests auf Stage bleiben.
So läuft das Plugin in Pipelines mit Docker, Staging und Preview URLs gegen jeden Merge Request.
Die Checks sind bewusst allgemein gehalten. Sie finden Fehler, die auf jeder Website auftreten können. Die Fachlogik deiner Anwendung kennen sie nicht. Ob ein Rabatt richtig berechnet wird oder ein Formular die richtige Mail verschickt, musst du weiter selbst testen.
Einige Checks sind auf den deutschen Markt zugeschnitten. ttValidateImprintClickable sucht nach einem Link mit dem Text Impressum, ttCookieAllAcceptClick nach Buttons wie alle akzeptieren. Für andere Sprachen übergibst du eigene Texte oder lässt den Check weg.
Ready-to-use tests for any website. No testing experience required.
Cypress Cloud MCP verbindet KI Agenten direkt mit Testergebnissen, Flaky Tests und Test Replay. Setup für OpenCode und Claude Code, eingeordnet von NCA.
Mehr erfahrenDas Plugin ist aus unserer Testing Arbeit entstanden und wird bis heute aktiv weiterentwickelt. Jede Version hat eigene Unit Tests mit Vitest und E2E Tests gegen eine kleine Testseite. Neue Commands kommen dazu, wenn wir in Projekten merken, dass wir denselben Check zum dritten Mal schreiben. Wie du solche Commands für dein eigenes Projekt baust, zeigt die Seite zu Cypress Custom Commands.
Für uns ist das Plugin der erste Baustein jeder Testsuite. Danach folgen die fachlichen Tests, die wir mit dem Team per Example Mapping erarbeiten. Bei Legacy Projekten sichern wir zuerst mit Characterization Tests ab und räumen erst dann auf, wie in der Legacy Modernisierung beschrieben.
Wenn KI Agenten Code schreiben, laufen die Checks in jeder Pipeline mit, passend zu den Vibe Coding CI/CD Pipelines und unserer Vibe Coding Beratung. Testergebnisse liest der Agent über Cypress Cloud MCP.
Im NCA Cypress Glossar: ESLint Plugin für Cypress, Cypress Grep, Cypress Parallelisierung und Flaky Tests in Cypress.
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.
Die wichtigsten Fragen zu Installation, Commands und Einsatz des Plugins.
Ein Open Source Plugin für Cypress, das fertige Tests für jede Website mitbringt. Es prüft Links, Bilder, SEO Grundlagen, HTTPS, Google Dienste und Barrierefreiheit mit einzelnen Commands. Das Paket heißt cypress-ncatestify-plugin, steht unter MIT Lizenz und wird von Never Code Alone gepflegt.
Das Plugin setzt Cypress 15 als Peer Dependency voraus. Dazu braucht es Node.js 22 oder ab Version 24, TypeScript 5 und Chai. Für den Accessibility Check kommen cypress-axe und axe-core dazu. Ältere Cypress Versionen werden von aktuellen Releases nicht mehr unterstützt.
Nein. Das Plugin ist Open Source unter MIT Lizenz und frei auf npm verfügbar. Du kannst es in privaten und kommerziellen Projekten nutzen, anpassen und weitergeben. Der Quellcode liegt öffentlich auf GitHub, Fehler und Wünsche kannst du dort als Issue melden.
Mit npm install cypress-ncatestify-plugin als Dev Abhängigkeit. Danach importierst du es in der Support Datei cypress/support/e2e.ts und setzt die baseUrl in der cypress.config.ts. Ab dann stehen alle Commands mit dem Präfix tt zur Verfügung, zum Beispiel cy.ttEveryInternalLinkStatusOk.
Für den Einstieg reicht ttValidatePageContent. Der Command bündelt Accessibility, Google Dienste, Bilder, interne Links, Impressum, H1 und HTTPS. Danach lohnen sich ttValidateSubpagesAndImages für Unterseiten mit Lazy Loading und ttThreshold, um das Seitengewicht dauerhaft im Blick zu behalten.
Die baseUrl ist die Grenze zwischen intern und extern. Nur Links auf dieselbe Domain gelten als intern und werden geprüft. Externe Links, mailto, tel und javascript Links filtert das Plugin automatisch heraus. Ohne baseUrl kann es diese Unterscheidung nicht treffen und bricht ab.
Ja. Die Link Commands nehmen eine Ausschlussliste als Argument. Jeder Link, dessen href einen der Texte enthält, wird übersprungen. Das ist praktisch für Logout Links, Downloads oder Bereiche, die in der Testumgebung bewusst nicht erreichbar sind.
Ja. Du schreibst Benutzer und Passwort für Basic Auth direkt in die baseUrl. Das Plugin reicht die Zugangsdaten an alle internen Requests weiter. In der CI Pipeline setzt du die URL als Umgebungsvariable CYPRESS_BASE_URL, damit keine Zugangsdaten im Repository landen.
Der Command beobachtet alle Requests an fremde Domains, während die Seite neu lädt. Findet er Aufrufe zu Google Fonts oder Google Maps, schlägt der Test fehl. So fallen Einbindungen auf, die ohne Einwilligung Daten an Google übertragen, etwa nach einem Theme Update.
Nein. Der Check nutzt axe-core und findet viele technische Fehler automatisch, etwa fehlende Labels oder schwache Kontraste. Ob eine Seite mit Tastatur und Screenreader wirklich gut bedienbar ist, zeigt aber nur eine manuelle Prüfung. Automatische Checks bilden die Grundlage, auf der das Audit aufbaut.
cy.ttEl wählt ein Element aus und gibt ihm einen sprechenden Namen für das Cypress Log. Statt eines kryptischen Selektors steht dort dann zum Beispiel submitButton. Das macht Testläufe und Fehlermeldungen lesbarer, gerade bei generierten IDs oder langen CSS Selektoren.
Sobald mehrere Tests dieselbe Seite bedienen. BasePage ist die Grundlage für Page Objects. Jeder Getter wird automatisch zum Namen im Log. Selektoren liegen an einer Stelle, und Tests lesen sich wie Abläufe. Bei kleinen Suiten reichen oft einzelne Commands.
