Comment faire en sorte que les tests de placeholder vides échouent intentionnellement à Mocha?

Je suis en train d'écrire une API de NodeJS et de tests à l'aide de Moka, de Chai et SuperTest. Je suis une utilisation typique d'un test-driven approche de l'écriture, les premiers tests satisfaire à ces tests avec le code de travail. Cependant, en raison du nombre de tests pour toutes les permutations différentes, j'ai commencé à écrire vide de l'espace réservé tests alors que j'ai tous les it('should...') descriptions en place pour me rappeler ce que pour tester, quand j'arrive à cette fonctionnalité. Par exemple:

it 'should not retrieve documents without an authorized user', (done) ->
    done()

Le problème, c'est que done() est appelé sans affirmation de sorte que le test est considéré comme en passant, j'ai donc ajouté de l'affirmation suivante.

false.should.equal true # force failure

mais c'est un hack et la raison de l'échec qui Moka affiche peut sembler déroutant, surtout quand d'autres tests peuvent être défaillants.

Est-il de toute manière officielle, intentionnellement, l'échec de l'espace réservé des tests de ce genre dans Mocha?

source d'informationauteur Soviut

La voie officielle pour marquer des essais comme n'étant pas prêt pour les essais pour skipqui est une méthode qui apparaît comme un champ de describe et it. Voici un exemple:

describe("not skipped", function () {
    it("bar", function () {
        throw new Error("fail");
    });

    it.skip("blah", function () {
        throw new Error("fail");
    });
});

describe.skip("skipped", function () {
    it("something", function () {
        throw new Error("fail");
    });
});

Le code ci-dessus, lorsqu'il est mis dans un test.js fichier et de l'exécuter avec $ mocha --reporter=spec test.jsproduit:

  not skipped
    1) bar
    - blah

  skipped
    - something


  0 passing (4ms)
  2 pending
  1 failing

  1) not skipped bar:
     Error: fail
      at Context.<anonymous> (/tmp/t33/test.js:3:15)
      at callFn (/home/ldd/local/lib/node_modules/mocha/lib/runnable.js:223:21)
      at Test.Runnable.run (/home/ldd/local/lib/node_modules/mocha/lib/runnable.js:216:7)
      at Runner.runTest (/home/ldd/local/lib/node_modules/mocha/lib/runner.js:374:10)
      at /home/ldd/local/lib/node_modules/mocha/lib/runner.js:452:12
      at next (/home/ldd/local/lib/node_modules/mocha/lib/runner.js:299:14)
      at /home/ldd/local/lib/node_modules/mocha/lib/runner.js:309:7
      at next (/home/ldd/local/lib/node_modules/mocha/lib/runner.js:247:23)
      at Object._onImmediate (/home/ldd/local/lib/node_modules/mocha/lib/runner.js:276:5)
      at processImmediate [as _immediateCallback] (timers.js:354:15)

Le test, les noms sont précédés par - sont ignorés. Aussi, dans un terminal qui prend en charge les couleurs les tests qui sont ignorés apparaissent en bleu (par opposition au rouge en cas d'échec des tests et vert pour le passage). Un sauté de test est dit être "en attente" afin de Moka indique le nombre de sauté tests "2 en attente".

De 05/19/2018 c'est officiel: https://mochajs.org/#pending-tests

Un test non implémenté ne devrait pas failil doit être marqué comme pending.

Un succincte de la méthode de marquage moka test not yet implemented est de ne pas passer à une fonction de rappel à la it gestionnaire.

describe("Traverse", function(){
    describe("calls the visitor function", function(){
        it("at every element inside an array")
        it("at every level of a tree")
    })
})

De course mocha test permettra d'afficher votre lettre morte tests en attente.

$ mocha test

  Traverse
    calls the visitor function
      - at every element inside an array
      - at every level of a tree


  0 passing (13ms)
  2 pending

6

Si vous passez une chaîne ou d'une erreur à done() il indique une erreur. Donc:
```
it 'should not retrieve documents without an authorized user', (done) ->
    done('not implemented')
```
serait la cause de la tester à l'échec avec la sortie:

done() invoquée avec les non-Erreur: pas de mise en œuvre

J'aime @Canyon de la solution de juste ne passant pas par un rappel pour marquer les tests "en attente", mais dans mon cas, je veux que ces espaces réservés à l'échec de mon CI s'appuie, afin de les rendre réels à défaut des tests de ce genre a été plus facile.
5

C'est effectivement une bonne question, parce que je voudrais aussi trouver ce super utile. Après l'avoir regardé, je pense que de simplement créer votre propre wrapper "todo" ou "échec" de la fonction que vous pouvez réutiliser tout au long de votre base de code.

Exemples ci-dessous utilisent une fonction appelée todo, qui permet d'imprimer le texte "n'est pas encore mis en œuvre". Cela peut être utile en tant que module séparé, même de sorte que vous pouvez les importer et les utiliser avec tous vos tests. Pourriez avoir besoin de modifier un peu le code...

Exemple dans le chai affirmer
```
var assert = require('chai').assert;

function todo() {
    assert(false, "method not yet implemented"); 
};

describe("some code", function(){
    it("should fail something", function(){
        todo();
    });
});
```
Exemple à l'aide de chai affirmer , avec l'échec de l'option (bien qu'il semble unncessary)
```
var assert = require('chai').assert;

function todo() {
    assert.fail(true, true, "method not yet implemented");   //1st 2 args can be anything really
};

describe("some code", function(){
    it("should fail something", function(){
        todo();
    });
});
```

Vous devez vous connecter pour publier un commentaire.