![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)
Carregado porAlex Tercete
Por que você não escreve Testes Unitários?
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.
![[DevOps Carioca] Testes Automatizados](https://cdn.slidesharecdn.com/ss_thumbnails/devopscariocatestesautomatizados-160515212330-thumbnail.jpg?width=640&height=640&fit=bounds)
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
- 2.
- 3. As quatro “desculpas” Nãosei 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 desenvolvemosatualmente 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
- 6.
- 7. Uma nova formade 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
- 8.
- 9. Código que testao código Classe de Produção Classe de Testes Test Doubles
- 10. Definição • Código quetesta 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 dotempo gasto Código sem testes Código com testes t t
- 13. Benefícios • Os errosaparecem 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) • Redede 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) • Melhorao 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 euquero ver um exemplo disso na prática!
- 19. Test-First Development • Escrevaos 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 osdetalhes do Arrange • Use somente uma linha no Act • Não se preocupe tanto com DRY no Assert
- 24. Manutenibilidade • Extraia aconstrução do objeto de teste • Os testes não devem te atrasar • Refatore o teste, também
- 25. Muito legal, maspor onde eu começo?
- 26. Just Do It! Umteste é melhor do que nenhum
- 27. Priorize o núcleodo sistema
- 28. Comece pela partemais 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 suastarefas, leve em conta o tempo necessário para escrever os testes
- 31.
- 32.
- 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.