Emplacement d'exécution des tests

Les tests automatisés peuvent généralement être exécutés en exécutant un script manuellement ou en utilisant un depuis un framework de test, souvent appelé exécuteur de test, pour rechercher et exécuter tests. Cependant, vous n'aurez peut-être pas toujours besoin d'exécuter vos scripts manuellement. Il existe plusieurs façons d'exécuter vos tests pour obtenir des commentaires et à différents stades du cycle de développement.

Script prérequis

Les projets Web disposent généralement d'un fichier de configuration (leur fichier package.json), soit configuré par npm, pnpm, Bun ou similaire. Ce fichier de configuration contient les dépendances du projet et d'autres informations, ainsi que les scripts d'aide. Ces des scripts d'aide peuvent inclure la manière de construire, d'exécuter ou de tester votre projet.

Dans package.json, vous devez ajouter un script appelé test qui décrit comment exécuter vos tests. C’est important parce que, lors de l’utilisation de npm ou d’une commande le test" a une signification particulière. Ce script peut simplement pointer vers un seul fichier qui génère une exception : une valeur semblable à node tests.js, mais nous vous recommandons de l'utiliser pour désigner un testeur établi.

Si vous utilisez Vitest en tant qu'exécuteur de test, votre Le fichier package.json doit se présenter comme suit:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

L'exécution de npm test avec ce fichier exécute une fois l'ensemble de tests par défaut de Vitest. Dans Par défaut, tous les fichiers se terminant par ".test.js" sont recherchés. ou similaires et les exécuter. En fonction de votre l'exécuteur de test choisi, la commande peut être légèrement différente.

Nous avons choisi d'utiliser Vitest, une infrastructure de test de plus en plus populaire, pour exemples tout au long de ce cours. Vous pouvez en savoir plus sur cette décision dans Vitest en tant que lanceur de test. Cependant, il est important de se rappeler que les frameworks de test et les exécuteurs, même et utilisent généralement un langage commun.

Appel de test manuel

Déclenchement manuel de vos tests automatisés (par exemple, en utilisant npm test dans les exemple précédent) peut être pratique lorsque vous travaillez activement sur un codebase. Écrire des tests pour une fonctionnalité tout en la développant peut vous aider à obtenir une idée du fonctionnement de la fonctionnalité. Cela touche le concept de développement piloté par les tests (TDD).

Les exécuteurs de test disposent généralement d'une courte commande que vous pouvez appeler pour exécuter une partie tous vos tests, et éventuellement un mode Observateur qui les réexécute au fur et à mesure que vous enregistrez de l'IA générative. Toutes ces options sont utiles lors du développement d'une nouvelle fonctionnalité, conçu pour faciliter l'écriture d'une nouvelle caractéristique, de ses tests ou des deux, avec un retour rapide. Vitest, par exemple, fonctionne en mode observateur par défaut: la commande vitest recherchera les modifications et réexécutera tous les tests qu'elle trouve. Mer nous vous recommandons de la laisser ouverte dans une autre fenêtre pendant que vous écrivez les tests. obtenir un retour rapide sur vos tests à mesure que vous les développez.

Certains exécuteurs vous permettent également de marquer les tests comme only dans votre code. Si votre code inclut des tests only, alors seuls ces tests se déclencheront lorsque vous exécuterez le test, ce qui rend le développement de tests plus rapide et plus facile à dépanner. Même si toutes vos les tests se terminent rapidement. L'utilisation de only peut vous aider à réduire vos frais généraux et à supprimer vous pouvez vous distraire d'exécuter des tests sans rapport avec la fonctionnalité ou le test sur lequel vous travaillez.

Pour les petits projets, en particulier ceux avec un seul développeur, vous pouvez également souhaitez prendre l'habitude d'exécuter régulièrement toute la suite de tests de votre codebase. Cela s'avère particulièrement utile si vos tests sont peu volumineux et qu'ils se terminent rapidement plus de quelques secondes pour tous vos tests) afin de vous assurer que tout fonctionne avant de passer à autre chose.

Exécuter des tests dans le cadre du préenvoi ou de l'examen

De nombreux projets choisissent de vérifier qu'un codebase fonctionne correctement doit être fusionné avec sa branche main. Si vous débutez avec les tests, avez contribué à des projets open source par le passé, vous l'avez probablement remarqué du processus de demande d'extraction (PR) confirme que tous les tests du projet Cela signifie que votre nouvelle contribution n'a pas eu d'impact négatif sur le projet existant.

Si vous exécutez vos tests en local, le dépôt en ligne de votre projet (par exemple, GitHub ou un autre service d'hébergement de code) ne sauront pas que vos tests sont concluants, Exécuter des tests en tant que tâche avant l'envoi indique donc clairement à tous les contributeurs que tout fonctionne correctement.

GitHub, par exemple, les appelle "vérifications de l'état" que vous pouvez ajouter via Actions GitHub. Les actions GitHub sont fondamentalement un type de test: chaque étape doit réussir (il ne doit pas échouer, ni générer Error) pour que l'action soit transmise. Vous pouvez appliquer des actions à tous les PR d'un projet, et un projet peut exiger que les actions soient validées avant de contribuer au code. GitHub L'action Node.js par défaut exécute npm test comme l'une de ses étapes.

</ph>

Cette approche de test tente de s'assurer que votre codebase est toujours "vert". en n'acceptant pas le code qui n'exécute pas correctement ses tests.

Exécuter des tests dans le cadre de l'intégration continue

Une fois que votre demande commerciale verte a été acceptée, la plupart des codebases exécutent à nouveau des tests en fonction la branche main de votre projet, plutôt que le PR précédent. Cela peut se produire immédiatement ou régulièrement (toutes les heures ou tous les soirs, par exemple). Ces les résultats sont souvent affichés dans un tableau de bord d'intégration continue (CI) montre l'état général du projet.

Cette étape d'intégration continue peut sembler redondante, en particulier pour les projets avec de petits codebases. ont réussi lors de l'examen. Par conséquent, ils devraient réussir dès qu'une modification aura été apportée. Toutefois, ce n'est pas toujours vrai ! Vos tests peuvent échouer soudainement, même s'ils sont concluants produisant des résultats verts. Voici quelques raisons à cela:

• Plusieurs modifications ont été acceptées « à la fois », parfois appelées condition de concurrence, et elles s'influencent mutuellement de manières subtiles et non testées.
• Vos tests ne sont pas reproductibles ou sont "imparfaits" dans le code source, ils peuvent tous les deux transmettre et échouent sans modification du code.
  • Cela peut se produire si vous dépendez de systèmes externes à votre codebase. Pour une un proxy, imaginez un test avec Math.random() > 0.05. Cela entraînerait un échec aléatoire de 5% du temps.
• Certains tests sont trop coûteux ou coûteux à exécuter sur chaque RP, comme les tests de bout en bout. des tests (plus d'informations à ce sujet dans la section Types de tests automatisés) et ils peuvent cesser de fonctionner avec le temps sans être toujours alerté.

Aucun de ces problèmes n'est impossible à surmonter, mais il convient de réaliser que les tests et le développement de logiciels en général, la science.

Un interlude sur le rollback

Lorsque les tests sont exécutés dans le cadre d'une intégration continue, et même lorsqu'ils sont lors d'une vérification de l'état, il est possible que la compilation se retrouve ou un autre état indiquant un échec des tests. Comme indiqué précédemment, cela peut se produire pour plusieurs raisons, y compris les conditions de concurrence ou des tests irréguliers.

Pour les petits projets, votre instinct pourrait être de les traiter comme une crise ! Arrêter effectuer un rollback ou annuler la modification incriminée, et revenir à une bon état. Cette approche peut être valable, mais il est important de garder à l'esprit que Les tests (et les logiciels en général) constituent un moyen d'atteindre une fin, et non un objectif lui-même. Votre objectif est probablement d'écrire un logiciel, et non de réussir tous les tests. À la place, vous pouvez avancer en effectuant le suivi de la modification destructive avec une autre qui corrige les échecs des tests.

D'autre part, vous avez peut-être vu ou travaillé sur de grands projets qui existent dans un état perpétuellement cassé. Ou pire, le grand projet a un test irrégulier qui font des pauses suffisamment fréquentes pour provoquer une fatigue liée aux alarmes chez les développeurs. Il s'agit souvent d'un problème existentiel à résoudre pour les responsables : les tests peuvent même être désactivés parce qu'ils sont considérés comme entravant développement."

Il n'existe pas de solution rapide à ce problème, mais cela peut vous aider à gagner en confiance lors de l'écriture (optimisation) et réduire la portée des tests (simplification) afin que les défaillances sont plus faciles à identifier. Augmentation du nombre de tests de composants ou les tests d'intégration (pour en savoir plus sur les types, consultez la section Types tests) peuvent vous apporter plus de confiance qu'un énorme test de bout en bout, difficile à gérer et qui essaie tout en même temps.

Ressources

• Quels sont les avantages des constructions nocturnes ?

Testez vos connaissances