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.
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.
- Cela peut se produire si vous dépendez de systèmes externes à votre codebase. Pour une
un proxy, imaginez un test avec
- 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
Testez vos connaissances
Quel est le nom du script spécial que npm et des programmes similaires recherchez-vous pendant les tests ?