Todos nós já sabemos como escrever testes automatizados. Mas podemos melhorar nisso? Por exemplo, como podemos ter certeza de que iremos além do “teste do caminho feliz” e criaremos conjuntos de testes realmente fortes? A cobertura de código é uma métrica ruim que devemos ignorar ou ela pode realmente nos ajudar? Devemos fazer testes unitários ou de integração? Ou os testes E2E são muito melhores para sistemas mais complexos? O TDD é realmente obrigatório? Ou podemos projetar sistemas testáveis sem ele?

Nesta palestra, compartilho lições que aprendi ao longo do tempo:

  1. O teste oferece suporte ao desenvolvimento e localização de bugs
  2. Ser sistemático ajuda a criar melhores casos de teste
  3. Insetos adoram limites
  4. A cobertura de código é uma boa ferramenta
  5. Testes de unidade versus testes de integração não importam; testes rápidos fazem
  6. Dividir para conquistar é a maneira de testar sistemas complexos
  7. O teste tem que ser fácil, caso contrário ninguém o fará
  8. TDD ou não TDD: o que importa é feedback rápido
  9. Tornar o código testável é a chave para a felicidade
  10. Você deve confiar no seu conjunto de testes
  11. Testar não é mágico!

Esta palestra é baseada em meu recente Teste de software eficaz: guia do desenvolvedor, publicado por Manning. Você pode comprar com 35% de desconto usando o código de desconto “au35ani”.

Vídeo

Agradeço ao CODAM pelo vídeo lindamente gravado!

Obrigado ACM Tech Talks pelo convite!

Apresentações

Link para a apresentação do Google Docs, se quiser reutilizá-la.

(Existem versões mais antigas desta apresentação, talvez você os tenha visto? Os slides podem ser um pouco diferentes da versão que você viu, pois vou melhorando-os à medida que avança!)