La documentation de http://visionmedia.github.io/mocha/ contient cet exemple:
describe('User', function(){ describe('#save()', function(){ it('should save without error', function(done){ var user = new User('Luna'); user.save(function(err){ if (err) throw err; done(); }); }) }) }) Je veux savoir quand je devrais imbriquer mes tests dans la fonction de describe et quel est le but fondamental de la describe . Puis-je comparer le premier premier argument passé pour describe les commentaires dans un langage de programmation? Rien n’est montré de describe dans la sortie sur la console. Est-ce uniquement pour des raisons de lisibilité ou est-ce qu’il y a d’autres utilisations pour cette fonction?
Y a-t-il quelque chose qui cloche si je l’utilise comme ça?
describe('User', function(){ describe('#save()', function(){ var user = new User('Luna'); user.save(function(err){ if (err) throw err; done(); }) }) })
Si je le fais de cette façon, le test passe toujours.
L’appel it identifie chaque test individuel mais it ne dit rien à lui seul sur la structure de votre suite de tests. Comment utilisez-vous l’appel de describe est ce qui donne une structure à votre suite de tests. Voici quelques-unes des choses que vous utilisez pour describe votre suite de tests. Voici un exemple de suite de tests simplifiée aux fins de discussion:
function Foo() { } describe("Foo", function () { var foo; beforeEach(function () { foo = new Foo(); }); describe("#clone", function () { beforeEach(function () { // Some other hook }); it("clones the object", function () { }); }); describe("#equals", function () { it("returns true when the object passed is the same", function () { }); it("returns false, when...", function () { }); }); afterEach(function () { // Destroy the foo that was created. // foo.destroy(); }); }); function Bar() { } describe("Bar", function () { describe("#clone", function () { it("clones the object", function () { }); }); });
Imaginez que Foo et Bar sont des classes à part entière. Foo a clone et equals méthodes. Bar a clone . La structure que j’ai ci-dessus est une façon possible de structurer les tests pour ces classes.
(La notation # est utilisée par certains systèmes (comme par exemple jsdoc) pour indiquer un champ d’instance. Ainsi, lorsqu’elle est utilisée avec un nom de méthode, elle indique une méthode appelée sur une instance de la classe (plutôt qu’une méthode de classe) a fait appel à la classe elle-même. La suite de tests fonctionnerait aussi bien sans la présence de # .)
Certains reporters de Mocha montrent les noms que vous donnez pour describe les rapports qu’ils produisent. Par exemple, le reporteur de spec (que vous pouvez utiliser en exécutant la $ mocha -R spec ) indiquerait:
Foo #clone ✓ clones the object #equals ✓ returns true when the object passed is the same ✓ returns false, when... Bar #clone ✓ clones the object 4 passing (4ms)
Si vous ne souhaitez exécuter que certains des tests, vous pouvez utiliser l’option --grep . Donc, si vous ne vous souciez que de la classe Bar , vous pouvez faire $ mocha -R spec --grep Bar et obtenir le résultat:
Bar #clone ✓ clones the object 1 passing (4ms)
Ou si vous ne voulez que les méthodes de clone de toutes les classes, alors $ mocha -R spec --grep '\bclone\b' et obtenez la sortie:
Foo #clone ✓ clones the object Bar #clone ✓ clones the object 2 passing (5ms)
La valeur donnée à --grep est interprétée comme une regex alors quand je passe \bclone\b je ne demande que le mot clone , et pas des choses comme des clones ou des cloned .
Dans l’exemple ci-dessus, les beforeEach et afterEach sont des hooks. Chaque crochet affecte les appels it qui se trouvent dans l’appel describe qui est le parent du hook. Les différents crochets sont:
beforeEach qui s’exécute avant chaque individu dans l’appel describe .
afterEach qui s’exécute après chaque individu dans l’appel describe .
before qui s’exécute une fois avant que l’individu à l’intérieur de l’appel describe soit exécuté.
after quoi s’exécute une fois après que tous les individus it contient sont describe .
Ces hooks peuvent être utilisés pour acquérir des ressources ou créer des structures de données nécessaires aux tests, puis libérer des ressources ou détruire ces structures (si nécessaire) une fois les tests terminés.
L’extrait de code que vous affichez à la fin de votre question ne génère pas d’erreur, mais ne contient aucun test, car les tests sont définis par it .
À ma connaissance, décrivez est vraiment juste là pour les humains … Donc, nous pouvons voir différents domaines de l’application. Vous pouvez nidifier n niveaux de profondeur.
describe('user',function(){ describe('create',function(){} });
Il est difficile d’append à l’excellente réponse de Louis. Il y a quelques avantages du bloc describe qu’il n’a pas mentionné, à savoir les fonctions skip and only .
describe.skip(...) { ... }
passera cette description et toutes ses descriptions nestedes et fonctionnera pendant que:
describe.only(...) { ... }
ne fera qu’exécuter cette description et ses descriptions nestedes et ses fonctions. Les modificateurs skip() et only() peuvent également être appliqués aux fonctions it ().
Décrire est simplement utilisé dans le but de comprendre le but des tests, il est également utilisé pour regrouper logiquement les tests. Disons que vous testez les API de la firebase database, que tous les tests de la firebase database peuvent être dans la description externe, de sorte que la description externe regroupe logiquement toutes les bases de données associées. Disons qu’il y a 10 API de firebase database à tester, chacune des fonctions de description internes définit ce que sont ces tests ….