Testes de integração, mas quanto?

Um debate recente dentro da minha equipe me fez pensar. O tópico básico é quanto e o que devemos cobrir com testes funcionais / de integração (com certeza, eles não são os mesmos, mas o exemplo é fictício onde não importa).

Digamos que você tenha uma classe "controller" algo como:

public class SomeController {
    @Autowired Validator val;
    @Autowired DataAccess da;
    @Autowired SomeTransformer tr;
    @Autowired Calculator calc;

    public boolean doCheck(Input input) {
        if (val.validate(input)) {
             return false;
        }

        List<Stuff> stuffs = da.loadStuffs(input);
        if (stuffs.isEmpty()) {
             return false;
        }

        BusinessStuff businessStuff = tr.transform(stuffs);
        if (null == businessStuff) {
            return false;
        }

       return calc.check(businessStuff);
    }
}

Precisamos de muitos testes de unidade com certeza (por exemplo, se a validação falhar ou se não houver dados no DB, ...), isso está fora de questão.

Nossa questão principal e sobre o que não podemos concordar é que a quantidade de testes de integração deve cobrir :-)

Estou do lado de que procuraremos menos testes de integração (pirâmide de teste). O que eu cobriria disso é apenas um caminho feliz e infeliz, em que a execução retorna da última linha, apenas para ver se eu coloco essas coisas juntas, não vai explodir.

O problema é que não é tão fácil dizer por que o teste resultou em falso, e isso faz com que alguns dos caras se sintam desconfortáveis ​​com ele (por exemplo, se simplesmente verificarmos apenas o valor de retorno, fica oculto que o teste é verde porque alguém alterou a validação e ela retorna false). Claro, sim, podemos cobrir todos os casos, mas isso seria um imho excessivo.

Alguém tem uma boa regra de ouro para esse tipo de problema? Ou uma recomendação? Lendo? Conversa? Postagem no blog? Alguma coisa sobre o assunto?

Muito obrigado antecipadamente!

PS: Procure o exemplo feio, mas é muito difícil traduzir uma parte específica do código em um exemplo. Sim, pode-se discutir sobre lançar exceções / usar um tipo de retorno diferente / etc. mas nossa mão está mais ou menos limitada por causa de dependências externas.

PS2: mudei este tópico de SO para cá (pergunta original, marcada em espera )

Existe uma escola de pensamento que questiona seriamente o valor dos testes de integração.

Suspeito que você obtenha um amplo espectro de respostas aqui, mas, na minha opinião, você só deve usá-las quando elas oferecerem um valor claro.

Primeiramente, você deve escrever o maior número possível de testes de unidade, porque a) eles são baratos eb) podem ser os únicos testes executados no servidor de compilação (se você tiver um).

É tentador escrever testes do lado do cliente para verificar o banco de dados ou alguma outra camada, mas eles devem realmente ocorrer no nível apropriado, se possível, em vez de criar um teste de integração. É claro que isso pode exigir algumas bases na forma de interfaces, etc.

Considere também o escopo do seu teste. Se você está simplesmente escrevendo um teste de integração para encobrir o que acontece de qualquer maneira quando seu conjunto é executado ou duplicando um teste de fumaça, isso tem valor limitado. Além disso, pense se mais log em locais pertinentes seria uma opção melhor do que receber uma mensagem obscura de uma dúzia de componentes interconectados e ter que rastreá-la.

Então, supondo que você tenha decidido escrever alguns, precisa pensar em quando eles serão executados. Se eles podem pegar algum problema desagradável, isso é ótimo, mas fica inútil se os desenvolvedores nunca se lembrarem de executá-los.

Por fim, os testes de integração são uma substituição totalmente inadequada para testes de fumaça e testes de usuários. Se você se preocupar com eles, eles devem formar uma pequena parte de um processo de teste bem projetado.

Contrariamente a essa resposta , considero o teste em diferentes níveis parte importante do processo de teste do software. Unidade, funcional, integração, fumaça, aceitação e outros tipos de testes estão testando coisas diferentes, e quanto mais, melhor.

E se você conseguir automatizá-los, eles poderão ser executados como um trabalho de sua integração contínua (como jenkins). Ninguém precisa executá-los para ver se eles quebraram, pois todos podem ver se os testes falharam.

Nos meus testes de integração, não entro em detalhes - detalhes e casos de canto são para testes de unidade. O que eu testei é apenas a principal funcionalidade, passando todos os parâmetros corretos. Isso significa que, no seu exemplo, nos testes de integração, eu não cobriria caminhos falsos.