Skip to content
Mithril.js 2
Main Navigation GuideAPI

Français

English
简体中文
繁體中文
Español
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Polski
Türkçe
čeština
magyar

Français

English
简体中文
繁體中文
Español
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Polski
Türkçe
čeština
magyar

Apparence

Sidebar Navigation

Bien démarrer

Installation

Application Simple

Ressources

JSX

ES6+ sur les navigateurs anciens

Animations

Tests

Exemples

Intégration de librairies externes

Gestion des Chemins

Concepts clés

Nœuds du DOM virtuel

Composants

Méthodes de cycle de vie

Keys

Le système de rafraîchissement automatique

Divers

Comparaison des frameworks

Migration depuis la version 1.x

Migration depuis la v0.2.x

API

Sur cette page

Tests ​

Configuration ​

Il est relativement facile de tester les applications Mithril.js. La manière la plus simple de commencer est d'utiliser ospec, mithril-query et JSDOM. L'installation de ces outils est très simple : ouvrez un terminal et exécutez la commande suivante.

bash
npm install --save-dev ospec mithril-query jsdom

Leur configuration est également relativement simple et nécessite quelques étapes courtes:

  1. Ajoutez "test": "ospec" à vos scripts npm dans votre fichier package.json. Voici un exemple, qui peut contenir d'autres champs pertinents pour votre projet:
json
{
  "name": "my-project",
  "scripts": {
    "test": "ospec --require ./test-setup.js"
  }
}
  1. Créez un fichier de configuration, test-setup.js, qui ressemble à ceci:
javascript
var o = require('ospec');
var jsdom = require('jsdom');
var dom = new jsdom.JSDOM('', {
  // Pour pouvoir utiliser `requestAnimationFrame`
  pretendToBeVisual: true,
});

// Définition des variables globales dont Mithril.js a besoin pour fonctionner.
// Les deux premières sont souvent utiles dans les tests.
global.window = dom.window;
global.document = dom.window.document;
global.requestAnimationFrame = dom.window.requestAnimationFrame;

// Importez Mithril.js pour vérifier qu'il se charge correctement.
require('mithril');

// Fermez JSDOM à la fin des tests.
o.after(function () {
  dom.window.close();
});
  1. Créez un composant, par exemple src/my-component.js, qui ressemble à ceci :
javascript
function MyComponent() {
  return {
    view: function (vnode) {
      return m('div', vnode.attrs.text);
    },
  };
}

module.exports = MyComponent;
  1. Et enfin, créez un fichier de test, par exemple src/tests/my-component.js, qui ressemble à ceci :
javascript
var mq = require('mithril-query');
var o = require('ospec');

var MyComponent = require('../my-component.js');

o.spec('MyComponent', function () {
  o('things are working', function () {
    var out = mq(MyComponent, { text: 'What a wonderful day to be alive!' });
    out.should.contain('day');
  });
});

Une fois que vous avez tout configuré, exécutez la commande suivante dans le même terminal où vous avez tout installé.

bash
npm test

Si vous avez tout configuré correctement, vous devriez obtenir un résultat qui ressemble à ceci :

––––––
All 1 assertions passed in 0ms

Bonnes pratiques ​

Les tests sont relativement simples dans la plupart des cas. Chaque test se compose généralement de trois parties : configurer l'état initial, exécuter le code et vérifier les résultats. Cependant, il y a des points à garder à l'esprit lors des tests pour en tirer le meilleur parti et gagner beaucoup de temps.

  1. Écrivez vos tests le plus tôt possible. Il n'est pas nécessaire de les écrire immédiatement, mais au moins au fur et à mesure que vous écrivez votre code. De cette façon, si les choses ne fonctionnent pas comme prévu, vous y consacrez 5 minutes maintenant, en sachant exactement ce qui se passe, au lieu de 5 jours d'affilée 6 mois plus tard, lorsque vous essayez de publier cette idée d'application incroyable qui est maintenant complètement dysfonctionnelle. Évitez de vous retrouver dans cette situation.

  2. Testez l'API, testez le comportement, mais ne testez pas l'implémentation. Tester qu'un événement est déclenché si une action particulière se produit est une bonne pratique. Cependant, n'incluez pas toute la structure DOM dans votre test. Vous ne voulez pas être obligé de réécrire une partie de 5 tests différents simplement parce que vous avez ajouté une simple classe liée au style. De même, vous ne voulez pas réécrire tous vos tests simplement parce que vous avez ajouté une nouvelle méthode d'instance à un objet.

  3. N'ayez pas peur de vous répéter et n'abstrayez que lorsque vous faites littéralement la même chose des dizaines ou des centaines de fois dans le même fichier, ou lorsque vous générez explicitement des tests. Normalement, dans le code, il est conseillé de tracer une ligne lorsque vous répétez la même logique plus de 2 à 3 fois et de l'abstraire dans une fonction. Cependant, lors des tests, même s'il y a beaucoup de logique en double, cette redondance fournit un contexte utile lors du débogage des tests. N'oubliez pas : les tests sont des spécifications, pas du code normal.

Tests unitaires ​

Les tests unitaires isolent des parties de votre application, généralement un seul module, mais parfois même une seule fonction, et les testent comme une seule "unité". Ils vérifient que, étant donné une entrée et un état initial particuliers, ils produisent la sortie et les effets secondaires souhaités. Cela peut sembler compliqué, mais ce n'est pas le cas. Voici quelques tests unitaires pour l'opérateur + de JavaScript, appliqué aux nombres :

javascript
o.spec('addition', function () {
  o('works with integers', function () {
    o(1 + 2).equals(3);
  });

  o('works with floats', function () {
    // Oui, merci IEEE-754 pour les nombres à virgule flottante bizarres.
    o(0.1 + 0.2).equals(0.30000000000000004);
  });
});

Tout comme vous pouvez tester unitairement des choses simples comme ça, vous pouvez également créer des tests unitaires pour des composants Mithril.js. Supposons que vous ayez ce composant :

javascript
// MyComponent.js
var m = require('mithril');

function MyComponent() {
  return {
    view: function (vnode) {
      return m('div', [
        vnode.attrs.type === 'goodbye' ? 'Goodbye, world!' : 'Hello, world!',
      ]);
    },
  };
}

module.exports = MyComponent;

Vous pourriez facilement créer quelques tests unitaires pour cela.

javascript
var mq = require('mithril-query');
var MyComponent = require('./MyComponent');

o.spec('MyComponent', function () {
  o("says 'Hello, world!' when `type` is `hello`", function () {
    var out = mq(MyComponent, { type: 'hello' });
    out.should.contain('Hello, world!');
  });

  o("says 'Goodbye, world!' when `type` is `goodbye`", function () {
    var out = mq(MyComponent, { type: 'goodbye' });
    out.should.contain('Goodbye, world!');
  });

  o("says 'Hello, world!' when no `type` is given", function () {
    var out = mq(MyComponent);
    out.should.contain('Hello, world!');
  });
});

Comme mentionné précédemment, les tests sont des spécifications. Vous pouvez voir à partir des tests comment le composant est censé fonctionner, et le composant le fait très efficacement.

Pager
Page précédenteAnimations
Page suivanteExemples

Publié sous la licence MIT.

Copyright (c) 2024 Mithril Contributors

https://mithril.js.org/testing.html

Publié sous la licence MIT.

Copyright (c) 2024 Mithril Contributors