Preciso testar tudo?

Vou iniciar meu primeiro projeto real em Ruby on Rails e estou me forçando a escrever testes TDD . Não vejo vantagens reais em escrever testes, mas como parece muito importante, tentarei.

É necessário testar todas as partes do meu aplicativo, incluindo páginas estáticas?

TDD não é sobre testes, é sobre design. Escrever os testes obriga a pensar em como a classe deve funcionar e que tipo de interface você precisa. Os testes são um efeito colateral feliz que facilita a refatoração mais tarde.

Então, com isso em mente, qual é o comportamento de uma página estática e qual é a interface?

Minha primeira resposta seria "none" e "none".

É sempre uma análise de custo-benefício. Qual é o custo do recurso para você? Se o custo for alto, teste bem e completamente. Se o custo for baixo, teste levemente ou de modo algum.

Há também o custo do tempo de colocação no mercado a considerar. Talvez seja melhor você fornecer um recurso que funcione principalmente do que chegar atrasado ao fornecer um recurso totalmente funcional.

É quase impossível responder a essas perguntas na IMO geral.

Eu acho que é mais importante preservar a capacidade de testar no caso de algum recurso ser mais importante do que você imaginou originalmente.

Eu diria "sim". Se você possui testes que abrangem até os recursos e códigos mais simples, pode ter certeza de que adicionar um novo código não faz com que o código no local pare de funcionar. Da mesma forma, fazer um teste para cada bug encontrado impede que as regressões retornem.

Sim, você deve testar tudo ...

Você não será capaz de escrever testes automatizados para tudo. Para suas páginas estáticas, use Selenium http://seleniumhq.org/ para garantir que as coisas estejam corretas.

Pela minha experiência, é quase impossível escrever alguns casos de front-end, mas é por isso que você realmente deseja testar usando o globo ocular Mark 1.

O teste é tão importante quanto a codificação. Você deve ouvir o ditado "Se algo pode dar errado, vai dar". INMO, dentre as várias técnicas de engenharia de software empregadas para aprimorar a qualidade, o teste é o mais valioso para ajudá-lo a encontrar problemas mais cedo.

Embora testar tudo não seja possível (especialmente com equipes pequenas e sistemas grandes), isso não significa que você pule o teste completamente. O teste vale a pena? Consulte a seção "Localizando falhas mais cedo" em Consulte Wiki-SoftwareTesting .

Os testes TDD também podem ser especificações vivas, se escritos dessa maneira. Os nomes dos métodos de teste devem fazer sentido para um usuário comercial.

Como outros já mencionaram, no teste do Ruby on Rails é muito mais importante do que na (maioria) outras línguas. Isso ocorre devido à falta de um compilador.

Idiomas como Delphi , C ++, VB.NET , etc ... são linguagens compiladas, e seu compilador irá captar muitos erros de digitação, como erros de digitação nas chamadas para um método. No Ruby on Rails, você só saberá se há um erro de digitação ou erro no seu código se essa linha de código específica for executada ou se você estiver usando um IDE que mostre avisos visuais.

Como TODAS as linhas de código são importantes (caso contrário, não estariam lá), você deve testar todos os métodos que escreve. Isso é muito mais simples do que parece, se você seguir algumas ferramentas básicas do TBDD.

Eu descobri que o Rails de Ryan Bates, lançado em How test, era inestimável para mim e realmente destacou a simplicidade do TBDD, se feito corretamente.

Se você estiver realmente usando a metodologia TDD, não escreverá o código sem antes ter um teste de unidade que está tentando passar.

Eu diria para não começar com TDD. Tome uma decisão informada quando gastar mais tempo aprendendo estratégias de arquitetura em geral. O TDD não permitirá que você pule essa lição de casa, embora possa começar a acreditar que sim.

Aqui está o meu problema com isso. Quando você diz que parece gastar muito tempo com coisas que nunca quebram os TDDs, você vai gostar quando uma coisa que você não previu em uma enorme cadeia de dependências é perdida. Quando você ressalta que é impossível prever essas coisas antes de escrever seu aplicativo, o que é ... por que testamos, eles dizem que é realmente mais sobre design e não sobre testes, mesmo que o teste seja útil.

Mas as cadeias gigantes de dependências vinculadas imprevisíveis não são o produto de um design ruim?

Então qual é?

Aqui está um pensamento. Não vamos ter enormes cadeias complexas de dependências, considerando os dois princípios a seguir do design orientado a objetos do Design Patterns:

"Programa para uma interface, não uma implementação"

Ou seja, seus objetos não devem se importar com quem está chamando ou como foram feitos. Somente que os argumentos adequados foram alimentados e que os métodos que eles chamam de outros objetos são direcionados para o trabalho conforme o esperado. Sua cadeia de dependência na maioria dos casos deve estar em um ponto de ligação, a chamada do método por parte do chamador e o local onde os argumentos são inseridos nos seus métodos. É aí que você registra, valida e envia mensagens úteis para depuração quando as coisas são ruins.

E:

"Favorecer a composição do objeto sobre a herança de classe"

Quem é o boneco? O cara que fez alguma coisa para uma classe em um esquema de herança em cascata complicado envolvendo cerca de 30 aulas, resultando em quebra de casos adicionais ou o desenvolvedor que criou essa arquitetura em primeiro lugar? O TDD pode ajudá-lo a entender os problemas dentro dessa torre inclinada da classe Pisa mais cedo do que você poderia ter sem, mas isso torna menos doloroso tentar modificar um dos pontos de extremidade desse desastre de código na próxima vez?

E é aí que chego à coisa que me incomoda. O TDD realmente ajuda a projetar ou permite uma arquitetura ruim? Parece-me que tem potencial para ser uma estratégia auto-realizável. Quanto mais sua equipe não tiver responsabilidade por arquitetura ruim, mais úteis esses componentes granulares de teste parecem se tornar, mas, em última análise, seu aplicativo se tornará uma PITA cada vez maior para trabalhar (supondo que eles nunca tenham pensado muito em arquitetura no primeiro Lugar, colocar). E deixar de reconhecer as conseqüências disso é sempre o erro mais caro que você pode cometer ao trabalhar em um aplicativo que deve ser atualizado e modificado ao longo do tempo.

Para responder à pergunta, pense em "o que poderia dar errado aqui". Em particular, se você alterar o "código" (marcação / qualquer que seja), como terá certeza de que não quebrou a página. Bem, para uma página estática:

• pode não renderizar
• pode renderizar incorretamente
• o JS pode não carregar
• os caminhos das imagens podem não funcionar
• os links podem estar quebrados

Pessoalmente, eu recomendaria:

• escreva um teste de selênio [1] que verifique se há uma sequência que você espera na página (na parte inferior, se possível). Isso valida a renderização.
• verifique se não há erros de JS (acho que o selênio permite isso)
• execute as páginas estáticas através de um validador html e, se possível, de um verificador de links.
• Não encontrei uma ferramenta que eu gostaria de validar JS, mas você pode ter sucesso com jslint ou jshint.

A conclusão aqui é que você deseja algo que seja repetível, fácil de usar e seja executado automaticamente no seu executor de teste.

Apenas para adicionar a todas as respostas já excelentes, eis o meu pensamento sobre o que testar e o que não testar:

Faça o teste:

• logíca de negócios
• lógica de aplicação
• funcionalidade
• comportamento,
• então, tudo, realmente, exceto :

Não teste:

• constantes
• apresentação

Portanto, não faz sentido fazer um teste que diz:

assert wibble = 3

e algum código que diz

wibble = 3

E também não faz sentido testar coisas de apresentação, como se o ícone está em pervinca azul, qual fonte você usou para títulos e assim por diante ...

Então, você pergunta: "devo testar páginas estáticas", e a resposta é: você as testa na medida em que fazem parte da funcionalidade, lógica de negócios ou comportamento do seu site.

Portanto, em nosso aplicativo, temos um teste que verifica se os termos e condições estão disponíveis em todas as partes do site - para usuários anônimos, usuários logados, painel, telas internas de aplicativos etc. Apenas verifica se há um link chamado "termos e condições" em cada página, que o link funcione e, em seguida, o teste diz que, quando chega à página, "se parece com" os C & Cs - apenas o suficiente para garantir que é a página certa, sem "testar uma constante" ou "testar a apresentação" ... para que você possa verificar se o texto está correto, por exemplo, sem verificar o tamanho da fonte ou o layout do texto em particular ...