Qual é o tamanho do meu projeto para eu testar? [fechadas]

Seu projeto já é grande o suficiente.

Na minha experiência, uma classe e uma função foram suficientes para considerar a necessidade de testes unitários.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

Eu nunca comprei a idéia "você deve testar tudo na unidade", embora certamente existam pessoas por aí que têm (veja resposta do mosquito !).

No que me diz respeito, os principais benefícios do teste unitário são:

1. Ajudar a garantir que as alterações não quebrem as coisas.
2. Ajudando você a criar interfaces sensatas para as suas aulas (já que isso obriga você a ser um cliente para o seu próprio código).
3. Ajudar a documentar como seu código deve ser usado.

Basicamente, você precisa ponderar o tempo que levará para escrever & manter testes contra esses fatores.

O número 1 geralmente é suficiente para valer a pena escrever testes. Na minha experiência, > 95% do código é modificado mais cedo ou mais tarde.

É simples: você não precisa testar a unidade se você descartar o programa depois de executá-lo uma vez.

Se isso parece excessivo para você, considere o que a alternativa significaria. Se houvesse algum tamanho abaixo do qual o teste unitário não pagasse, você teria que continuar julgando em sua mente: "Já alcancei o tamanho mágico? Devo começar a escrever testes?" Agora, os programadores são notoriamente ruins em prever o futuro, e eles são notoriamente ruins em julgar suas próprias habilidades. Código que parece cristalino para você agora se tornará incompreensível, até mesmo para você, mesmo esperando por um mês. Um projeto que você está absolutamente certo de que nunca será usado novamente, e que você mantém apenas a remota chance de querer descobrir como você resolveu algo antes, será solicitado novamente, e receberá solicitações de mudança.

Algum tempo atrás eu encontrei um post legal: Por que o teste de unidade acelera o desenvolvimento . Pode ajudá-lo a responder a pergunta.

...What if the codebase... was provided with a substantial set of unit tests. A set that would say : “if all tests succeed, I guarantee that code still does what it should do” and if a test fails it exactly shows you where some behavior is broken . This is great, I could change the code to add things I want without wandering if the code still does what it should do, I just run the... tests and I have faith. This is a great world to be in as a software engineer. I noticed that I could advance way faster...

I have “faith”.

This is probably the most important reason why unit tests speed up development in a enterprise context.

I can trust that everything still works if all tests pass. If tests fail they will point out exactly where the problem lays...

...you have to have a high unit test coverage and good unit tests. When these conditions are respected you’ll find yourself in a situation that the effort for adding new functionality ‘s is almost independent of the size of the application and that in the long run it will speed up development.

Michael Feathers introduziu em um de seus livros duas maneiras de trabalhar com mudanças no código:

• edite e ore,
• cobrir e modificar.

Não importa quão grande seja o código base.

De acordo com Kent Beck em sua resposta à pergunta Stack Overflow Quantos são os seus testes de unidade? , você deve testar o código que você tende a errar.

If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it.

Testes de unidade são implementados para economizar tempo e melhorar:

• acompanhamento de bugs
• refatoração e / ou reescrita do código
• testes de integração
• testes de regressão, etc.

É necessário escrever testes de unidade para partes relativamente complexas do programa.

Se tiver certeza de que a gravação de testes de unidade não economizará seu tempo no futuro, você poderá ignorá-la. No entanto, você nunca sabe e, pessoalmente, não consigo pensar em um caso em que seja mais barato (no sentido de tempo, dinheiro e nervosismo) não escrever testes de unidade, mas sim fazer todos os testes manualmente.

"Se eu testar unidade isso" geralmente pode ser respondido respondendo a seguinte pergunta: "É importante que esta função funcione corretamente, e é importante para mim saber quando ela para de funcionar?"

Claro, é muito mais complicado do que isso, mas é uma boa maneira de começar. Eventualmente você também pesará se o código já está sendo testado em virtude de ser usado em outra função, ou se seu tempo seria melhor gasto em outra função, etc.

A menos que você escreva código sem testá-lo, você sempre incorrerá no custo do teste.

A diferença entre ter testes de unidade e não tê-los é a diferença entre o custo de escrever o teste e o custo de executá-lo em comparação com o custo do teste manual.

Se o custo de escrever um teste de unidade for de 2 minutos e o custo de execução do teste de unidade for praticamente 0, mas o custo de testar manualmente o código for 1 minuto, você quebrará mesmo depois de executar o teste duas vezes.

Por muitos anos, fiquei sem entender que não tinha tempo suficiente para escrever testes de unidade para o meu código. Quando eu escrevia testes, eles estavam inchados, coisas pesadas que só me encorajavam a pensar que eu só deveria escrever testes de unidade quando eu soubesse que eles eram necessários.

Recentemente, fui encorajado a usar o Test Driven Development e descobri que era uma revelação completa. Agora estou firmemente convencido de que não tenho o tempo não para escrever testes unitários.

Na minha experiência, desenvolvendo com testes em mente você acaba com interfaces mais limpas, classes mais focadas & módulos e geralmente mais SOLID , código testável.

Toda vez que eu trabalho com código legado que não tem testes de unidade e eu tenho que testar manualmente algo, eu continuo pensando "isso seria muito mais rápido se esse código já tivesse testes de unidade". Toda vez que eu tenho que tentar adicionar funcionalidade de teste de unidade ao código com alto acoplamento, eu continuo pensando "isso seria muito mais fácil se tivesse sido escrito de uma forma desacoplada".

TL; DR versão:

Escreva um teste quando o custo de escrever o teste, mais o custo de executá-lo tantas vezes quantas forem necessárias, provavelmente será menor do que o custo de testá-lo manualmente quantas vezes precisar.

Lembre-se que se você usar o TDD, o custo de escrever testes provavelmente diminuirá à medida que você melhorar, e a menos que o código seja absolutamente trivial, você provavelmente acabará executando seus testes mais frequentemente do que o esperado.

Teste assim que você observar que as regressões acontecem ou teme causar algumas alterações nas suas edições e não notar.

Acenda esse medo, deixe-o crescer até um tamanho adequado: quanto mais cedo você testar, melhor.

Por favor note: dependendo da sua função no projeto, os testes unitários podem não ser o único tipo de teste que você quer escrever.

Todo mundo é obcecado por testes de unidades, por causa de práticas ruins de testes no passado; mas se você nunca testou antes, você deve focar no teste em geral , o teste de unidade sozinho não resolve os problemas do mundo.

Acredito que não é o tamanho do projeto, mas o tipo de projeto que decide se deve usar testes ou não.

Se você está trabalhando em uma prova de conceito ou em algum outro projeto em que o objetivo é aprender com a codificação, o teste não é necessário. Se o projeto é destinado a ser usado, talvez até mesmo enviado para produção, então ele deve ser testado.

Uma citação de "Código Limpo" de Robert C. Martin : "Se é trivial escrever, é trivial para testar ", então não há desculpa para pular o teste para programas curtos e triviais.

Realmente não é uma questão de tamanho - é o que você faz com ele (e quantos anos ele tem). Se eu estou aprendendo como uma tecnologia funciona e planejo jogar a coisa fora (nós chamamos isso de um pico no Scrum), eu simplesmente codifico sem fazer muitos testes. Se você está planejando desenvolvê-lo ainda mais (mesmo se você estiver apenas por aí), você deve escrever testes em torno do código. O TDD é uma técnica de design antes mesmo de ser uma técnica de teste. Você quer ter uma imagem clara do que deseja que o código faça antes de se ligar aos detalhes da execução. Eu também NÃO recomendo tentar escrever extensos testes de unidade em torno de grandes quantidades de código legado. Tente identificar as partes que são complexas (têm uma alta complexidade ciclomática / código de espaguete para elas) e aquelas que falham com frequência (elas geralmente são as mesmas). Como outros sugeriram, eu iria ler o livro de Kent Beck sobre TDD e definitivamente ler o livro de Michael Feather. O que eles não cobrem muito é o aspecto político para escrever testes de unidade em torno do código. Muitos desenvolvedores detestam alterar seu código para torná-lo testável, e muitos desenvolvedores não sentem a necessidade de testar o código. É algo em que temos que trabalhar como profissão. Todas as outras disciplinas de engenharia são necessárias para provar (muitas vezes matematicamente) que seu trabalho atendeu à especificação. Nós devemos fazer o mesmo.

Ligar projetos em limites de classes ou funcionalidades e, em seguida, julgar se isso é adequado para testes de unidade pode estar errado. Existem inúmeros benefícios de testar um aplicativo em uma unidade, mas a beleza real começa quando você precisa manter um aplicativo ou precisa trabalhar em um ambiente distribuído. Então a escolha vem aqui. Mesmo uma pequena alteração no seu código pode causar desastres.
Eu não apenas sugeriria 'Teste de Unidade', mas também recomendaria verificar sua cobertura de código, garantindo que o máximo de seu código seja coberto pelo Teste de Unidade. O limite para a cobertura do código não deve ser menor que 95% e o alvo deve estar em torno de 100% . Você pode ir para ferramentas para rastrear sua cobertura de código e gerar um relatório.
O Visual Studio fornece dados de cobertura - link Você também pode usar NCover ou dotCover.