Webdriverio: Couverture de code

Créé le 4 janv. 2016  ·  3Commentaires  ·  Source: webdriverio/webdriverio

Est-il prévu d'inclure la couverture du code ? J'ai trouvé https://github.com/gotwarlost/istanbul/issues/132 mais il ne semble pas y avoir de bonne façon de le faire. (Je suis particulièrement intéressé par le concombre)

Commentaire le plus utile

Parce qu'avec WebdriverIO, vous écrivez des tests e2e qui devraient tester les cas commerciaux de bout en bout (comme son nom l'indique). Vous ne testez donc pas du code mais un flux utilisateur spécifique. Vous essayez de couvrir tous les aspects commerciaux de votre application. Même si vous pouvez techniquement capturer la quantité de code qui a été exécuté dans le frontend, cela n'a aucun sens car ce n'est pas du tout intéressant pour vos analyses de rentabilisation.

Avec les tests unitaires, vous testez réellement le code et, par conséquent, la couverture du code est importante pour voir dans quelle mesure vous vous en sortez avec vos tests. Dans ce cas, il a une valeur.

N'hésitez pas à capturer le rapport de couverture dans le test fonctionnel, mais vous finirez par essayer de rendre ce rapport beau en écrivant plus de tests e2e au lieu de tests unitaires ou de tests d'intégration. Tout dépend de ce que vous essayez de tester et des outils que vous utilisez pour cela.

Tous les 3 commentaires

Tout d'abord, je ne pense pas que la couverture de code devrait faire partie de vos tests d'intégration. Vous devez d'abord écrire des tests unitaires et vous assurer que vous disposez d'une couverture de code décente. Selenium/WebdriverIO devrait alors couvrir l'intégration de bout en bout de votre stack.

Cependant, vous pouvez faire la même chose que décrit dans ce fil de discussion en utilisant WebdriverIO. Au lieu d'utiliser la syntaxe de selenium-webdriver, utilisez simplement les commandes WebdriverIOs :

    client.execute("return window.__coverage__;").then(function (obj) {
        var str = JSON.stringify(obj);
        var options = {
            port: 8888,
            host: "localhost",
            path: "/coverage/client",
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            }
        };
        var req = http.request(options, function (res) {
            console.log("\nFinished sending coverage data.");
            done();
        });
        req.write(str);
        req.end();
    });

Mais encore une fois, vous ne devez pas inclure de couverture de code dans vos tests d'intégration.

@christian-bromann

je me demande pourquoi vous pensez que les rapports de couverture ne devraient pas faire partie des tests fonctionnels

Parce qu'avec WebdriverIO, vous écrivez des tests e2e qui devraient tester les cas commerciaux de bout en bout (comme son nom l'indique). Vous ne testez donc pas du code mais un flux utilisateur spécifique. Vous essayez de couvrir tous les aspects commerciaux de votre application. Même si vous pouvez techniquement capturer la quantité de code qui a été exécuté dans le frontend, cela n'a aucun sens car ce n'est pas du tout intéressant pour vos analyses de rentabilisation.

Avec les tests unitaires, vous testez réellement le code et, par conséquent, la couverture du code est importante pour voir dans quelle mesure vous vous en sortez avec vos tests. Dans ce cas, il a une valeur.

N'hésitez pas à capturer le rapport de couverture dans le test fonctionnel, mais vous finirez par essayer de rendre ce rapport beau en écrivant plus de tests e2e au lieu de tests unitaires ou de tests d'intégration. Tout dépend de ce que vous essayez de tester et des outils que vous utilisez pour cela.

Cette page vous a été utile?
0 / 5 - 0 notes