[Compilation et partage] Quelques frameworks de tests utilisables dans Node.js

NodeQuels frameworks de tests peuvent être utilisés ? L'article suivant partagera avec vous quelques frameworks de test Node.js. J'espère qu'il vous sera utile !

Note de l'éditeur : L'auteur de cet article est Tianzhu, ingénieur chez Ant Group Node.js Tout d'abord, il présentera les bibliothèques de classes couramment utilisées pour chaque partie. Discutez si les tests unitaires sont nécessaires. Bienvenue pour en discuter ensemble.

Les bibliothèques et outils de classes couramment utilisés

L'exécuteur de cas de test

mocha et jest sont plus couramment utilisés. Le nouveau node test officiel est toujours en cours de peaufinage et l'avenir est prometteur.

$ mocha

  test/egg-view-ejs.test.js
    render
      ✓ should render with locals
      ✓ should render with cache
      ✓ should render with layout
      ✓ should render error
    renderString
      ✓ should renderString with data
      ✓ should renderString error

  6 passing (398ms)

Bien qu'il y ait tellement de coureurs, leurs normes de sortie sont toutes au format TAP, puis les résultats sont publiés via différents journalistes.

Statistiques de couverture

Écrire un seul test ne suffit pas. 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.

Auparavant, c'était istanbuljs, et plus tard l'auteur l'a réécrit en nyc. Ils assument principalement deux responsabilités : l'une est de traduire le code pour insérer le code d'empilage, et l'autre est d'aider divers journalistes à générer une couverture. rapports.

Plus tard, les statistiques de couverture intégrées à la 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 nativement prise en charge.

Ensuite, cet auteur a écrit c8 qui se concentre sur la génération de rapports de couverture.

Bibliothèque de classes Assert

Pour vérifier les résultats des variables, l'assertion est essentielle.

Il y a eu dans l'histoire : expect.js, should.js, chai et power-assert, jest a aussi sa propre attente intégrée.

Mais maintenant, le assert/strict officiel de Node.js est en fait plutôt bon.

Parmi eux, power-assert est ce que nous utilisons tout le temps chez EggJS. Je l'ai également utilisé 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');

describe('test/showcase.test.js', () => {
  const arr = [ 1, 2, 3 ];

  it('power-assert', () => {
    assert(arr[1] === 10);
  });
});

// output:
4) test/showcase.test.js power-assert:

      AssertionError:   # test/showcase.test.js:6

  assert(arr[1] === 10)
         |  |   |
         |  2   false
         [1,2,3]

  [number] 10
  => 10
  [number] arr[1]
  => 2

PS : Si vous souhaitez vérifier le contenu du fichier, j'ai également écrit un assert-file, ​​​​n'hésitez pas à l'essayer.

Bibliothèque de classes Mock & Stub

Parce qu'il s'agit d'un test unitaire, il est souvent nécessaire de simuler l'environnement ou les réponses en aval.

sinonjs Pas mal, prend en charge les mocks, les stubs, etc. jest possède également sa propre bibliothèque fictive intégrée.

S'il s'agit d'un test HTTP, nock est très puissant et peut vous aider à simuler la réponse du serveur.

nock('http://www.example.com')
  .post('/login', 'username=pgte&password=123456')
  .reply(200, { id: '123ABC' })

Cependant, la bibliothèque de requêtes undici officiellement publiée par Node.js possède également des 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.

Bibliothèque de tests HTTP

Pour tester les scénarios du serveur HTTP, la bibliothèque supertest est indispensable.

describe('GET /users', function() {
  it('responds with json', async function() {
    return request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200)
      .then(response => {
        assert(response.body.email, 'foo@bar.com');
      });
  });
});

Bibliothèque de tests de ligne de commande

L'un des scénarios d'utilisation de Node.js est la CLI de ligne de commande, telle que Webpack, Babel, etc., qui elles-mêmes doivent également disposer de tests unitaires.

Cette recommandation est ce que nous avons écrit :

• GitHub - node-modules/clet : Command Line E2E Testing

• GitHub - node-modules/coffee : Tester la ligne de commande sur Node.js

  import { runner, KEYS } from 'clet';

  it('devrait fonctionner avec passe-partout', async() => { attendre le coureur() .cwd(tmpDir, { init : true }) .spawn('npm init') .stdin(/name:/, 'example') // attend la sortie standard, puis répond .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // valide la sortie standard .notStderr(/npm ERR/) .file('package.json', { nom : 'exemple', version : '1.0.0' }) // valider le fichier });

Outil de test automatisé de pages Web

Explorez légèrement les pages, vous pouvez utiliser directement la bibliothèque de requêtes HTTP, recommandée undici.

Pour simuler l'exécution réelle du navigateur, au début il s'agissait de selenium et phantomjs.

Puis Google a officiellement publié puppeteer En raison de l'accumulation de Chromium et basé sur le protocole devtools-protocol, il est rapidement devenu très populaire et a tué les deux premiers. Les produits concurrents similaires incluent playwright et cypress.

À propos, macacajs est 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.

Service d'intégration continue

Lorsque nous écrivons de l'open source, nous avons souvent besoin de services d'intégration continue automatisés pour nous aider à tester.

Les joueurs dans ce domaine incluent : Travis, Appveyor, GitHub Actions, etc.

Maintenant, j'utilise essentiellement GitHub Actions, le niveau d'intégration est tellement cool.

Discussion : Les tests unitaires sont-ils nécessaires ?

Il ne fait aucun doute que les tests unitaires sont très importants. C'est une capacité et une qualité professionnelle nécessaires d'un programmeur qualifié.

Bien sûr, 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.

1. L'écriture de tests unitaires est-elle une perte de temps ?

Tout d'abord, permettez-moi de corriger le point de vue d'un nouveau venu courant : Écrire des tests unitaires est 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 les tests de régression après chaque modification de code » :

• Lors de l'écriture d'un seul test, créez différents branche se moque au début , le temps des tests de régression consiste simplement à taper au clavier
• Sans écrire un seul test, vous devez mettre à jour le code dans l'application, puis simuler manuellement diverses situations à tester, comme l'ouverture d'un navigateur ; et en cliquant sur de nombreux endroits différents.

Le temps que prennent ces deux tâches est clairement visible 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 balance lorsqu'elle prend des décisions après avoir pesé le poids.

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 dans certains front-end orientés UI applications ou applications rapides qui ont beaucoup changé, Le coût de maintenance des tests uniques correspondant pour les pages d'activité montantes et descendantes 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, qui consiste à automatiser la comparaison basée sur les différences, puis à rappeler au propriétaire de faire 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.

2. Les tests unitaires ne devraient-ils pas être écrits par des programmeurs ?

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 doit effectuer des 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 des tests d'intégration, des tests de régression, des tests de bout en bout, etc. Travail de grand niveau.

La division du travail est différente, ne blâmez pas les autres.

donc...

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.

Pour plus de connaissances sur les nœuds, veuillez visiter : tutoriel Nodejs !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!