Webdriverio: Cobertura de código

Em primeiro lugar, não acho que a cobertura de código deva fazer parte de seus testes de integração. Você deve escrever testes de unidade primeiro e certificar-se de ter uma cobertura de código decente lá. O Selenium/WebdriverIO deve cobrir a integração de ponta a ponta de sua pilha.

No entanto, você pode fazer o mesmo conforme descrito nesse tópico de problema usando o WebdriverIO. Em vez de usar a sintaxe do selenium-webdriver, basta usar os comandos do 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();
    });

Mas, novamente, você não deve incluir cobertura de código em seus testes de integração.

@christian-bromann

estou me perguntando por que você acredita que os relatórios de cobertura não devem fazer parte dos testes funcionais

Porque com o WebdriverIO você escreve testes e2e que devem testar casos de negócios de ponta a ponta (como o nome indica). Portanto, você não está testando código, mas um fluxo de usuário específico. Você tenta cobrir todos os aspectos comerciais do seu aplicativo. Mesmo que você tecnicamente possa capturar a quantidade de código que foi executada no frontend, isso não faz sentido porque não é interessante para seus casos de negócios.

Com os testes de unidade, você realmente testa o código e, portanto, a cobertura do código é importante para ver o quão bem você está se saindo com seus testes. Neste caso tem um valor.

Sinta-se à vontade para capturar o relatório de cobertura no teste funcional, mas você acabará tentando fazer esse relatório parecer bom escrevendo mais testes e2e em vez de testes de unidade ou testes de integração. É tudo sobre o que você está tentando testar e quais ferramentas você está usando para isso.