Cypress est un outil de test end-to-end (E2E) qui simule un vrai utilisateur dans un vrai navigateur pour vérifier que ton application web fonctionne correctement de bout en bout. Autrement dit, au lieu de tester des fonctions isolées, tu testes le parcours complet : l’utilisateur clique sur un bouton, remplit un formulaire, voit apparaître un résultat. Tout ça, automatiquement, à chaque fois que tu modifies ton code.
Si tu as déjà livré une fonctionnalité qui marchait parfaitement en local et qui était cassée en production, Cypress est fait pour toi. C’est exactement le genre de bug qu’il attrape avant que ton utilisateur ne le découvre.
Pourquoi Cypress s’est imposé comme la référence des tests E2E ?
Avant Cypress, tester une interface web était une vraie galère : les outils comme Selenium étaient lents, instables, et nécessitaient une configuration complexe qui rebutait beaucoup de développeurs. Cypress est arrivé avec une promesse simple : des tests rapides, lisibles, et qui tournent directement dans le navigateur.
La différence fondamentale avec ses concurrents, c’est que Cypress s’exécute dans le même contexte que ton application. Il n’y a pas de couche intermédiaire entre le test et le navigateur. Résultat : les tests sont stables, les erreurs sont précises, et le débogage devient humain.
En 2026, Cypress dépasse les 50 millions de téléchargements par semaine sur npm. C’est l’un des outils les plus adoptés dans les équipes front-end, que ce soit sur des projets React, Vue, Angular ou même du HTML vanilla.
Si tu veux comprendre comment tester des fonctions JavaScript unitaires avant de passer aux tests E2E, jette un œil à comment tester ton code JavaScript avec Jest sans jamais livrer un bug en production. Les deux approches se complètent parfaitement.
Comment installer et configurer Cypress en moins de 5 minutes ?
L’installation de Cypress est l’une des plus rapides de l’écosystème JavaScript : une commande suffit pour avoir un environnement de test complet et fonctionnel.
Dans ton projet, lance cette commande :
npm install cypress --save-devEnsuite, ouvre Cypress avec :
npx cypress openUne interface graphique s’ouvre. Cypress te propose de choisir entre deux modes : E2E Testing (ce qu’on va utiliser) et Component Testing (pour tester des composants isolés). Sélectionne E2E, choisis ton navigateur, et Cypress génère automatiquement une configuration de base dans un fichier cypress.config.js.
Ton dossier cypress/ est créé avec cette structure :
cypress/e2e/: tes fichiers de testscypress/fixtures/: tes données de test (JSON)cypress/support/: tes commandes personnalisées
C’est tout. Pas de configuration XML, pas de drivers à télécharger manuellement. Ça tourne.
Comment écrire ton premier test Cypress de zéro ?
Un test Cypress se lit comme une phrase en anglais : tu décris ce que l’utilisateur fait, et Cypress vérifie que le résultat est correct.
Crée un fichier cypress/e2e/accueil.cy.js et colle ce code :
describe('Page d accueil', () => {
it('affiche le titre principal', () => {
// Visite la page
cy.visit('https://ton-site.com')
// Vérifie que le titre existe et contient ce texte
cy.get('h1').should('contain', 'Bienvenue')
})
it('redirige vers le formulaire au clic sur le bouton', () => {
cy.visit('https://ton-site.com')
// Clique sur le bouton
cy.get('button[data-cy="cta"]').click()
// Vérifie que l'URL a changé
cy.url().should('include', '/formulaire')
})
})Lance le test avec npx cypress open, clique sur ton fichier et regarde Cypress jouer le scénario en direct dans le navigateur. Tu vois chaque étape s’exécuter, et si quelque chose échoue, tu vois exactement où et pourquoi.
La commande cy.get() est ton outil principal. Elle sélectionne un élément du DOM. L’attribut data-cy est une convention recommandée par Cypress pour identifier les éléments sans dépendre des classes CSS ou des IDs qui peuvent changer.
Quelles sont les commandes Cypress les plus utiles à connaître ?
Cypress dispose d’une API riche mais cohérente : une fois que tu connais la logique de base, tu peux écrire des tests complexes très rapidement.
| Commande | Ce qu’elle fait | Exemple |
|---|---|---|
| cy.visit() | Ouvre une URL | cy.visit('/login') |
| cy.get() | Sélectionne un élément | cy.get('input[name="email"]') |
| cy.type() | Tape du texte dans un champ | .type('[email protected]') |
| cy.click() | Clique sur un élément | cy.get('button').click() |
| cy.should() | Vérifie une condition | .should('be.visible') |
| cy.intercept() | Intercepte une requête réseau | cy.intercept('GET', '/api/users') |
La commande cy.intercept() mérite une attention particulière. Elle te permet de simuler des réponses d’API sans avoir besoin d’un vrai backend. Tu peux tester le comportement de ton interface quand une API renvoie une erreur 500, par exemple, sans avoir à casser ton serveur.
Comment intégrer Cypress dans un projet avec TypeScript ou Vite ?
Cypress s’intègre naturellement dans les stacks modernes, que tu utilises TypeScript, Vite ou un framework comme Next.js.
Pour TypeScript, ajoute un fichier cypress/tsconfig.json :
{
"compilerOptions": {
"target": "es5",
"lib": ["es5", "dom"],
"types": ["cypress", "node"]
},
"include": ["./**/*.ts"]
}Ensuite, renomme tes fichiers de tests en .cy.ts au lieu de .cy.js. Cypress supporte TypeScript nativement depuis la version 10, aucun plugin supplémentaire n’est nécessaire.
Si tu utilises Vite.js comme outil de build, tu peux activer le mode Component Testing de Cypress avec le plugin officiel @cypress/vite-dev-server. Ça te permet de tester tes composants en isolation, exactement comme le ferait Storybook pour visualiser tes composants UI, mais en vérifiant leur comportement réel.
Et si tu travailles avec TypeScript au quotidien, consulte notre guide sur les erreurs TypeScript les plus fréquentes chez les débutants pour éviter les pièges classiques dans tes fichiers de tests.
Cypress vs Playwright : lequel choisir en 2026 ?
Playwright est le principal concurrent de Cypress depuis 2023, et la question revient souvent dans les équipes qui démarrent leur stratégie de tests E2E.
| Critère | Cypress | Playwright |
|---|---|---|
| Prise en main | Très facile | Facile |
| Interface graphique | Oui, excellent | Oui, bon |
| Multi-navigateurs | Chrome, Firefox, Edge | Chrome, Firefox, Safari, Edge |
| Multi-onglets | Limité | Natif |
| Vitesse en CI | Bonne | Très bonne |
| Communauté | Très large | En forte croissance |
La réponse courte : si tu démarres, choisis Cypress. L’interface graphique est incomparable pour apprendre, voir tes tests s’exécuter en direct est une aide précieuse. Si tu as des besoins avancés (tests sur Safari, gestion de plusieurs onglets, performances en CI sur de gros projets), Playwright devient pertinent. Mais pour 90% des projets d’une équipe standard, Cypress fait très bien le travail.
Comment lancer Cypress en mode headless dans une CI/CD ?
Le mode headless permet d’exécuter tes tests Cypress sans interface graphique, ce qui est indispensable dans un pipeline d’intégration continue comme GitHub Actions ou GitLab CI.
La commande est simple :
npx cypress runPar défaut, Cypress tourne en headless avec Electron. Tu peux spécifier un navigateur :
npx cypress run --browser chromePour GitHub Actions, voici une configuration minimale dans .github/workflows/tests.yml :
name: Tests E2E
on: [push]
jobs:
cypress:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: cypress-io/github-action@v6
with:
start: npm start
wait-on: 'http://localhost:3000'L’action officielle cypress-io/github-action gère automatiquement le démarrage de ton application et l’attente que le serveur soit prêt avant de lancer les tests. Pas besoin de bricoler.
En résumé : Cypress
Cypress est l’outil de référence pour tester ton interface utilisateur de façon automatisée en 2026. Son installation prend moins de 5 minutes, son interface graphique rend le débogage accessible même aux débutants, et son intégration dans une CI est simple. Tu écris des tests qui ressemblent à ce qu’un utilisateur ferait réellement, et Cypress vérifie que tout fonctionne à ta place. Si tu veux arrêter de livrer des bugs en production et professionnaliser ta façon de coder, c’est un des meilleurs investissements que tu puisses faire dans ton stack de développement.
Questions fréquentes sur Cypress
Cypress est-il gratuit ?
L’outil open source est entièrement gratuit et couvre la grande majorité des besoins. Cypress propose aussi une offre Cloud payante (anciennement Cypress Dashboard) pour gérer l’historique des tests, la parallélisation et les rapports d’équipe. Mais pour un projet solo ou une petite équipe, la version gratuite suffit largement.
Cypress peut-il tester des applications mobiles ?
Non. Cypress est conçu pour les applications web dans un navigateur de bureau. Il peut simuler une vue mobile en redimensionnant la fenêtre avec cy.viewport('iphone-x'), mais il ne teste pas de vraies applications iOS ou Android. Pour ça, il faudrait te tourner vers des outils comme Detox ou Appium.
Quelle est la différence entre un test unitaire et un test E2E avec Cypress ?
Un test unitaire vérifie une fonction isolée : tu donnes une entrée, tu vérifies la sortie. Un test E2E avec Cypress simule un parcours utilisateur complet dans un vrai navigateur : il visite une page, clique, remplit des formulaires, et vérifie que le résultat affiché est correct. Les deux sont complémentaires et ne remplacent pas l’un l’autre.
Cypress fonctionne-t-il avec tous les frameworks JavaScript ?
Oui. Cypress fonctionne avec n’importe quelle application accessible via une URL, qu’elle soit construite avec React, Vue, Angular, Svelte, Astro ou même du HTML statique. Il ne dépend pas du framework, uniquement du navigateur.
Combien de temps faut-il pour apprendre Cypress ?
Pour écrire tes premiers tests fonctionnels, compte une demi-journée. La documentation officielle de Cypress est reconnue comme l’une des meilleures de l’écosystème JavaScript. En une semaine de pratique régulière, tu peux couvrir les scénarios les plus courants de ton application.
Faut-il un backend actif pour faire tourner les tests Cypress ?
Non, pas forcément. Cypress propose la commande cy.intercept() qui te permet de simuler toutes les réponses de ton API. Tu peux tester ton interface avec des données fictives, sans avoir besoin d’un serveur réel. C’est très utile pour tester des cas d’erreur ou des états particuliers difficiles à reproduire en conditions réelles.