Quels frameworks de tests peuvent être utilisés pour Node ? L'article suivant partagera avec vous quelques frameworks de test Node.js. J'espère qu'il vous sera utile ! 
Cours d'introduction rapide à Node.js : participez pour apprendre
Note de l'éditeur : L'auteur de cet article est Tianzhu, un ingénieur Node.js chez Ant Group. Il présentera d'abord les bibliothèques de classes couramment utilisées dans chaque partie, et expliquera si les tests unitaires sont nécessaires. pour discuter ensemble.
le moka et la plaisanterie sont couramment utilisés. Le test officiel du nouveau nœud est toujours en cours de peaufinage et l’avenir est prometteur.
$moka test/egg-view-ejs.test.js rendre ✓ devrait être rendu avec les locaux ✓ devrait être rendu avec le cache ✓ devrait être rendu avec la mise en page ✓ devrait afficher une erreur chaîne de rendu ✓ devrait renderString avec des données ✓ devrait erreur renderString 6 passes (398 ms)
Bien qu'il y ait un grand nombre de Runners, leurs normes de sortie sont toutes au format TAP et les résultats sont publiés via différents Reporters.
Il ne suffit pas d'écrire un seul test. Nous devons savoir si tous les processus de branche du code sont couverts, nous devons donc généralement utiliser des outils de couverture de code.
C'était autrefois Istanbul, mais plus tard, l'auteur a réécrit New York. Ils assument principalement deux responsabilités : l'une consiste à traduire le code pour insérer le code d'empilage et l'autre est d'aider divers journalistes à générer des rapports de couverture.
Plus tard, statistiques de couverture intégrées V8
, c'est-à-dire qu'il n'est plus nécessaire de traduire le code et que la collecte de données de couverture est prise en charge de manière native.
Ensuite, cet auteur a écrit un c8 axé sur la génération de rapports de couverture.
Pour vérifier des résultats variables, l’assertion est essentielle.
Historiquement : expect.js, Should.js, chai et power-assert, jest a également sa propre attente intégrée.
Mais maintenant, l'assert/strict officiel de Node.js est en fait plutôt bon.
Parmi eux, power-assert est ce que nous utilisons chez EggJS. Je l'ai également mentionné il y a de nombreuses années : "Probablement la meilleure bibliothèque JS Assert - Les nouveaux vêtements de l'empereur".
const assert = require('power-assert');
décrire('test/showcase.test.js', () => {
constarr = [1, 2, 3];
it('affirmation de pouvoir', () => {
assert(arr[1] === 10);
});
});
//sortir:
4) test/showcase.test.js power-assert :
AssertionError : # test/showcase.test.js:6
affirmer(arr[1] === 10)
|
| 2 faux
[1,2,3]
[numéro] 10
=> 10
[numéro] arr[1]
=> 2PS : Si vous souhaitez vérifier le contenu du fichier, j'ai également écrit un fichier assert, n'hésitez pas à l'essayer.
S'agissant d'un test unitaire, il est souvent nécessaire de simuler l'environnement ou les réponses en aval.
sinonjs n'est pas mauvais et prend en charge les simulations, les stubs, etc. jest possède également sa propre bibliothèque fictive intégrée.
S'il s'agit de tests HTTP, nock est très puissant et peut vous aider à simuler la réponse du serveur.
encoche('http://www.example.com')
.post('/login', 'username=pgte&password=123456')
.reply(200, { identifiant : '123ABC' })Cependant, la bibliothèque officielle de requêtes undici de Node.js dispose également de fonctionnalités Mock intégrées.
Il existe également un terme appelé instantané, qui signifie vider les données pendant le fonctionnement et les utiliser directement comme données fictives pour le prochain test, ce qui peut améliorer dans une certaine mesure l'efficacité de l'écriture des tests.
Pour tester les scénarios HTTP Server, la bibliothèque supertest est indispensable.
décrire('GET /utilisateurs', fonction() {
it('répond avec json', fonction asynchrone() {
demande de retour (application)
.get('/utilisateurs')
.set('Accepter', 'application/json')
.expect('Content-Type', /json/)
.attendre(200)
.then(réponse => {
assert(response.body.email, '[email protected]');
});
});
});L'un des principaux scénarios d'utilisation de Node.js est la CLI de ligne de commande, telle que Webpack et Babel, qui elles-mêmes nécessitent également des tests unitaires.
Voici ce que nous recommandons :
GitHub - node-modules/clet : tests E2E en ligne de commande
GitHub - node-modules/coffee : tester la ligne de commande sur Node.js
importer { runner, KEYS } depuis 'clet' ;
it('devrait fonctionner avec passe-partout', async () => { wait runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // attendez la sortie standard, puis répondez .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // validez la sortie standard .notStderr(/ npm ERR/) .file('package.json', { nom : 'exemple', version : '1.0.0' }) // valider le fichier });
Pour une exploration légère des pages, vous pouvez directement utiliser HTTP pour demander la bibliothèque Unci.
Pour simuler l'exécution réelle du navigateur, Selenium et phantomjs ont été utilisés au début.
Ensuite, Google a officiellement publié Puppeteer. En raison de l'accumulation de Chromium et basé sur le protocole devtools, il est rapidement devenu populaire et a tué les deux premiers. Les produits concurrents similaires incluent le dramaturge et le cyprès.
À propos, je vais télécharger macacajs, un outil de test multi-terminal. En plus des navigateurs, il prend également en charge les tests d'applications mobiles et d'applications de bureau. Il est open source par les ingénieurs de l'équipe Yuque.
Lorsque nous écrivons de l'open source, nous avons souvent besoin de services d'intégration continue automatisés pour nous aider à tester.
Les acteurs dans ce domaine incluent : Travis, Appveyor, GitHub Actions, etc.
Maintenant, j'utilise essentiellement GitHub Actions, et le niveau d'intégration est vraiment cool.
Il ne fait aucun doute que les tests unitaires sont très importants. Il s’agit d’une capacité et d’une qualité professionnelle nécessaires pour un programmeur qualifié.
Bien entendu, nous ne sommes pas des fanatiques de la couverture à 100 %. Dans de nombreux cas, nous devons rechercher le point d’équilibre du retour sur investissement.
Tout d’abord, permettez-moi de corriger le point de vue d’un nouveau venu : l’écriture de tests unitaires est-elle une perte de temps ?
En fait, écrire des tests unitaires vous fera gagner du temps. La raison de cette vision contre-intuitive est que les conditions de comparaison ne sont souvent pas objectives. Nous devons considérer le coût de la régression après avoir modifié le code deux fois avec les mêmes exigences de qualité.
Pour une comparaison juste, en plus de considérer le « temps pour écrire un seul test », ce qui est facilement négligé est le « temps pour effectuer des tests de régression après chaque modification de code » :
Lorsque vous écrivez un seul test, créez plusieurs simulations de branche dès le début, et le temps des tests de régression consiste simplement à taper sur le clavier ;
Sans écrire un seul test, vous devez mettre à jour le code dans l'application, puis simuler manuellement diverses situations à tester, comme ouvrir un navigateur et cliquer à de nombreux endroits différents.
Le temps que ces deux tâches prennent est évident en un coup d’œil.
Ce n'est rien de plus qu'un investissement initial + un coût de maintenance + l'accent mis sur la qualité du retour. Chaque entreprise a sa propre échelle lorsqu'elle prend des décisions après les avoir pesées.
Bien sûr, la plupart des scénarios que j'ai mentionnés sont des bibliothèques de framework (y compris front-end et Node.js), des applications côté serveur, des outils de ligne de commande, etc. Il est vrai que certaines applications frontales qui présentent un changement important dans L'affichage de l'interface utilisateur ou le chargement et le déchargement rapides sont Pour la page d'activité, le coût de maintenance des tests uniques correspondant est en effet très élevé. À l'heure actuelle, il est raisonnable d'abandonner de manière appropriée les tests uniques de certaines branches non essentielles en fonction du retour sur investissement.
Mais nous devons comprendre qu'il s'agit d'un dernier recours. Nous pouvons réduire le coût de maintenance des tests unitaires par divers moyens, mais nous ne pouvons pas prétendre que les tests unitaires sont inutiles.
Il existe également un test de régression semi-automatique dans le domaine front-end, basé sur les différences pour automatiser la comparaison, puis rappeler au propriétaire de prêter attention à l'impact des changements. C'est exactement comme les bibliothèques d'outils ci-dessus, qui sont toutes là pour aider à réduire le coût d'écriture de tests uniques.
C'est également une vision erronée. Les tests unitaires doivent être écrits par les programmeurs eux-mêmes , car il s'agit de votre propre code et vous devez en être responsable. Toute équipe avec un peu de standardisation a besoin de tests CI lors de la soumission du code, sinon il n'y aura pas de collaboration de qualité en matière de révision du code.
Les étudiants de test sont responsables de travaux de plus grande envergure tels que les tests d'intégration, les tests de régression et les tests de bout en bout .
La division du travail est différente, alors ne blâmez pas les autres.
Les tests unitaires sont très nécessaires. L'écriture de tests unitaires est la qualité professionnelle de base des programmeurs. Écrivez autant que vous le pouvez. Dans des scénarios individuels, vous pouvez faire des choix en fonction du retour sur investissement.