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.
npm install --save-dev ospec mithril-query jsdom
Leur configuration est également relativement simple et nécessite quelques étapes courtes:
- Ajoutez
"test": "ospec"
à vos scripts npm dans votre fichierpackage.json
. Voici un exemple, qui peut contenir d'autres champs pertinents pour votre projet:
{
"name": "my-project",
"scripts": {
"test": "ospec --require ./test-setup.js"
}
}
- Créez un fichier de configuration,
test-setup.js
, qui ressemble à ceci:
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();
});
- Créez un composant, par exemple
src/my-component.js
, qui ressemble à ceci :
function MyComponent() {
return {
view: function (vnode) {
return m('div', vnode.attrs.text);
},
};
}
module.exports = MyComponent;
- Et enfin, créez un fichier de test, par exemple
src/tests/my-component.js
, qui ressemble à ceci :
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é.
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.
É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.
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.
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 :
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 :
// 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.
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.