Conteúdo

Por que não testamos software? Porque é caro? Porque é demorado? Porque é chato? Testes automatizados são a solução para todos esses problemas. Aprenda a escrever um programa que teste seu programa de forma rápida, barata e produtiva, e aumente a qualidade do seu produto final.

Neste livro, você aprenderá sobre TDD, uma das práticas ágeis de desenvolvimento de software mais populares, através da linguagem Java, mas poderá aplicar o conceito aprendido em qualquer outra linguagem. TDD faz o desenvolvedor escrever o teste antes mesmo de implementar o código. Essa simples inversão na maneira de se trabalhar faz com o que o desenvolvedor escreva um código mais testado, com menos bugs, e, inclusive, com mais qualidade. Seja profissional, teste seu software!

Todos os exemplos desse livro foram escritos em Java.

Saiba o que você vai aprender

Sumário

• 1 Introdução
• 1.1 Era uma vez um projeto sem testes...
• 1.2 Por que devemos testar?
• 1.3 Por que não testamos?
• 1.4 Testes automatizados e TDD
• 1.5 Conclusão
• 1.6 Como tirar dúvidas?

• 2 Testes de Unidade
• 2.1 O que é um teste de unidade?
• 2.2 Preciso mesmo escrevê-los?
• 2.3 O Primeiro Teste de Unidade
• 2.4 Continuando a testar
• 2.5 Conclusão

• 3 Introdução ao Test-Driven Development
• 3.1 O problema dos números romanos
• 3.2 O primeiro teste
• 3.3 Refletindo sobre o assunto
• 3.4 Quais as vantagens?
• 3.5 Um pouco da história de TDD
• 3.6 Conclusão

• 4 Simplicidade e Baby Steps
• 4.1 O problema do cálculo de salário
• 4.2 Implementando da maneira mais simples possível
• 4.3 Passos de bebê (ou Baby steps)
• 4.4 Usando baby steps de maneira consciente
• 4.5 Conclusão

• 5 TDD e design de classes
• 5.1 O problema do carrinho de compras
• 5.2 Testes que influenciam no design de classes
• 5.3 Diferenças entre TDD e testes da maneira tradicional
• 5.4 Testes como rascunho
• 5.5 Conclusão

• 6 Qualidade no código do teste
• 6.1 Repetição de código entre testes
• 6.2 Nomenclatura dos testes
• 6.3 Test Data Builders
• 6.4 Testes repetidos
• 6.5 Escrevendo boas asserções
• 6.6 Testando listas
• 6.7 Separando as classes de teste
• 6.8 Conclusão

• 7 TDD e a coesão
• 7.1 Novamente o problema do cálculo de salário
• 7.2 Ouvindo o feedback dos testes
• 7.3 Testes em métodos privados?
• 7.4 Resolvendo o problema da calculadora de salário
• 7.5 O que olhar no teste em relação a coesão?
• 7.6 Conclusão

• 8 TDD e o acoplamento
• 8.1 O problema da nota fiscal
• 8.2 Mock Objects
• 8.3 Dependências explícitas
• 8.4 Ouvindo o feedback dos testes
• 8.5 Classes estáveis
• 8.6 Resolvendo o problema da nota fiscal
• 8.7 Testando métodos estáticos
• 8.8 TDD e a constante criação de interfaces
• 8.9 O que olhar no teste em relação ao acoplamento?
• 8.10 Conclusão

• 9 TDD e o encapsulamento
• 9.1 O problema do processador de boleto
• 9.2 Ouvindo o feedback dos testes
• 9.3 Tell, Don't Ask e Lei de Demeter
• 9.4 Resolvendo o problema do processador de boletos
• 9.5 O que olhar no teste em relação ao encapsulamento?
• 9.6 Conclusão

• 10 Testes de integração e TDD
• 10.1 Testes de unidade, integração e sistema
• 10.2 Quando não usar mocks?
• 10.3 Testes em DAOs
• 10.4 Devo usar TDD em testes de integração?
• 10.5 Testes em aplicações Web
• 10.6 Conclusão

• 11 Quando não usar TDD?
• 11.1 Quando não praticar TDD?
• 11.2 100% de cobertura de código?
• 11.3 Devo testar códigos simples?
• 11.4 Erros comuns durante a prática de TDD
• 11.5 Como convencer seu chefe sobre TDD?
• 11.6 TDD em sistemas legados
• 11.7 Conclusão

• 12 E agora?
• 12.1 Como aprender mais agora?
• 12.2 Dificuldade no aprendizado
• 12.3 Como interagir com outros praticantes?
• 12.4 Conclusão final

• 13 Apêndice: princípios SOLID
• 13.1 Sintomas de projetos de classes em degradação
• 13.2 Princípios de projeto de classes
• 13.3 Conclusão