Por que você não escreve Testes Unitários?
2 gostaram666 visualizações
O documento discute os benefícios de escrever testes unitários, como eles melhoram o design do código e reduzem erros. Apresenta o desenvolvimento guiado por testes (TDD) como uma abordagem onde os testes são escritos antes do código de produção para definir a funcionalidade requerida. Também descreve como testes unitários automatizados melhoram a qualidade e manutenibilidade do código.
![Escrever testes unitário é fácil
[Test]
public void TesteDePotenciacao()
{
// Arrange
var calculadora = new Calculadora();
// Act
var resultado = calculadora.Eleva(3, 4);
// Assert
Assert.Equal(81, resultado);
}](https://image.slidesharecdn.com/testesunitrios-130628151043-phpapp01/85/Por-que-voce-nao-escreve-Testes-Unitarios-16-320.jpg)
Por que você não escreve Testes Unitários?
- 1. Por que você não escreve Testes Unitários? Alex Tercete alex.tercete@vtex.com.br
- 3. As quatro “desculpas” Não sei do que se trata Não sei como Não tenho tempo Eu já escrevo
- 4. Você provavelmente já faz testes Clique, clique, clique Debug Console Application Testes automatizados
- 5. Escrever código Como desenvolvemos atualmente Camada de apresentação (UI) Camada de Serviço Camada de Lógica Camada de Acesso a Dados “Clicar no botão” Funcionou? DEBUG Não Comemorar! Sim
- 7. Uma nova forma de pensar Camada X Escrever teste Implementar funcionalidade Terminou? Não Fim Sim Camada Y Escrever teste Implementar funcionalidade Terminou? Não Fim Sim Camada Z Escrever teste Implementar funcionalidade Terminou? Não Fim Sim
- 9. Código que testa o código Classe de Produção Classe de Testes Test Doubles
- 10. Definição • Código que testa o código – O código testa o teste (?) • Um por unidade de código – Uma classe de teste por classe de código – Vários métodos de teste por método de código • Não interagem com elementos externos • Automatizados • Reproduzíveis
- 11. Mas isso não é trabalho dobrado?
- 12. Uma análise do tempo gasto Código sem testes Código com testes t t
- 13. Benefícios • Os erros aparecem cedo – Reduz o ciclo de feedback – Quem corrige é quem gerou • Garante o comportamento correto do sistema – Reduz a quantidade de erros – Aumenta a “qualidade” dos erros
- 14. Benefícios (2) • Rede de proteção – Evita regressão – Aumenta a confiança do desenvolvedor – Encoraja refatoração • Ajuda aos outros desenvolvedores – Código mais limpo – Documentação sempre atualizada – Mais segurança pra mexer no código “dos outros”
- 15. Benefícios (3) • Melhora o design do código – Você escreve apenas o necessário para satisfazer os requisitos dos testes – O teste é seu primeiro “cliente” • Continuous Delivery – Mais segurança no deploy
- 16. Escrever testes unitário é fácil [Test] public void TesteDePotenciacao() { // Arrange var calculadora = new Calculadora(); // Act var resultado = calculadora.Eleva(3, 4); // Assert Assert.Equal(81, resultado); }
- 17. O desafio é escrever código testável Código testável Teste Código não testável
- 18. Tá, mas eu quero ver um exemplo disso na prática!
- 19. Test-First Development • Escreva os testes antes de escrever o código • Desenvolva a API que você gostaria de consumir • Antes de corrigir um erro, escreva um teste que o exponha • Nunca escreva código sem um teste falhando
- 20. Pontos de “costura” • (Desnecessário) • Construtor • Propriedade • Herde e sobrescreva – Aumenta a legibilidade e a manutenibilidade do teste • Encapsule – Reduz a manutenibilidade
- 21. O teste é mais importante do que a implementação
- 22. Nomenclatura • Assembly.De.Codigo.Tests – Vtex.Practices.ServiceModel.Tests • ClasseDeCodigoTests – HttpMethodResolverTests • Metodo_de_testes_bem_descritivo – Resolve_to_GET_when_using_HttpGet
- 23. Legibilidade • Esconde os detalhes do Arrange • Use somente uma linha no Act • Não se preocupe tanto com DRY no Assert
- 24. Manutenibilidade • Extraia a construção do objeto de teste • Os testes não devem te atrasar • Refatore o teste, também
- 25. Muito legal, mas por onde eu começo?
- 26. Just Do It! Um teste é melhor do que nenhum
- 27. Priorize o núcleo do sistema
- 28. Comece pela parte mais fácil • Métodos com entrada e saída bem definidas • Métodos com poucas dependências
- 29. Erre bastante • Pesquise • Peça ajuda • Aprenda • Evolua
- 30. Ao estimar suas tarefas, leve em conta o tempo necessário para escrever os testes
- 31. Mensagem final
- 33. Referências • http://elegantcode.com/2008/05/20/get-started- writing-testable-code/ • http://www.martinfowler.com/bliki/TestDouble.h tml • http://googletesting.blogspot.com/2008/11/clean -code-talks-unit-testing.html • http://misko.hevery.com/attachments/Guide- Writing%20Testable%20Code.pdf • http://googletesting.blogspot.com/2008/08/by- miko-hevery-so-you-decided-to.html • http://hashbucket.wordpress.com/2009/01/12/u nit-testing-internal-methods/
- 34. Livros