Test-Driven Development Teste e Design no Mundo Real com .NET
Mauricio AnicheTest-Driven Development com .net
Agradecimentos
Essa talvez seja a seção mais difícil de se escrever, pois a quantidade de pessoas que participaram direta ou indiretamente do livro é muito grande.
Vou começar agradecendo ao meu pai, mãe e irmão, que a todo momento me apoiaram na decisão de fazer um mestrado, entender como ciência deve ser feita, e que sofreram junto comigo nos momentos de grande estresse (que todo mestrado proporciona!).
Agradeço também ao meu orientador de mestrado e doutorado, prof. Dr. Marco Aurelio Gerosa, que me ensinou como as coisas funcionam "do lado de lá". Sem ele, acho que esse livro seria muito diferente; seria mais apaixonado, porém menos verdadeiro. Se meu texto olha TDD de maneira fria e imparcial, a culpa é dele.
Os srs. Paulo Silveira e Adriano Almeida também merecem uma lembrança. Mesmo na época em que a Casa do Código não existia de fato, eles já haviam aceitado a ideia do livro de TDD. Obrigado pela confiança.
Todas as pessoas das últimas empresas em que atuei também me ajudaram muito com as incontáveis conversas de corredor sobre o assunto. Isso com certeza enriqueceu muito o texto.
Agradeço também aos amigos José Donizetti, Guilherme Moreira e Rafael Ferreira, que gastaram tempo lendo o livro e me dando sugestões de como melhorar.
Ao leitor Alan Walking, que leu meu livro com muita atenção e me mandou diversos e-mails com sugestões e correções. Escrever um livro não é fácil; toda ajuda é bem vinda.
Por fim, obrigado a você que está lendo esse livro. Espero que ele ajude.
Quem sou eu?
Meu nome é Mauricio Aniche e trabalho com desenvolvimento de software há por volta de 10 anos. Em boa parte desses 10 anos, atuei como consultor para diferentes empresas do mercado brasileiro e internacional. Com certeza, as linguagens mais utilizadas por mim ao longo da minha carreira foram Java, C# e C.
Como sempre pulei de projeto em projeto (e, por consequência, de tecnologia em tecnologia), nunca fui a fundo em nenhuma delas. Pelo contrário, sempre foquei em entender princípios que pudessem ser levados de uma para outra para que, no fim, o código saísse com qualidade, independente da tecnologia.
Em meu último ano da graduação, 2007, comecei a ler mais sobre a ideia de testes automatizados e TDD. Achei muito interessante e útil a ideia de se escrever um programa para testar seu programa, e decidi praticar TDD, por conta própria, para entender melhor como ela funcionava.
Gostei muito do que vi. De 2007 em diante, resolvi praticar, pesquisar e divulgar melhor minhas ideias sobre o assunto. Comecei devagar, apenas blogando o que estava na minha cabeça e sobre o que gostaria de receber feedback de outros desenvolvedores. Mas para fazer isso de maneira mais decente, resolvi ingressar no programa de Mestrado da Universidade de São Paulo. Lá, pesquisei sobre os efeitos da prática de TDD no design de classes.
Ao longo desse tempo participei da grande maioria dos eventos relacionados ao assunto. Palestrei nos principais eventos de métodos ágeis do país (como Agile Brazil, Encontro Ágil), de desenvolvimento de software (QCON SP e DNAD), entre outros menores. Cheguei a participar de eventos internacionais também; fui o único palestrante brasileiro no Primeiro Workshop Internacional sobre TDD, em 2010, na cidade de Paris. Isso mostra também que tenho participado dos eventos acadêmicos. Em 2011, apresentei um estudo sobre TDD no WBMA (Workshop Brasileiro de Métodos Ágeis), e em 2012, no maior simpósio brasileiro sobre engenharia de software, o SBES.
Atualmente trabalho pela Caelum, como consultor e instrutor. Também sou aluno de doutorado pela Universidade de São Paulo, onde continuo a pesquisar sobre a relação dos testes de unidade e qualidade do código.
Portanto, esse é meu relacionamento com TDD. Nos últimos anos tenho olhado ele de todos os pontos de vista possíveis: de praticante, de acadêmico, de pesquisador, de apaixonado, de frio. Esse livro é o relato de tudo que aprendi nesses últimos anos.
Prefácio
TDD é uma das práticas de desenvolvimento de software sugeridas por diversas metodologias ágeis, como XP. A ideia é fazer com que o desenvolvedor escreva testes automatizados de maneira constante ao longo do desenvolvimento. Mas, diferentemente do que estamos acostumados, TDD sugere que o desenvolvedor escreva o teste antes mesmo da implementação.
Essa simples inversão no ciclo traz diversos benefícios para o projeto. Baterias de testes tendem a ser maiores, cobrindo mais casos, e garantindo uma maior qualidade externa. Além disso, escrever testes de unidade forçará o desenvolvedor a escrever um código de maior qualidade pois, como veremos ao longo do livro, para escrever bons testes de unidade, o desenvolvedor é obrigado a fazer bom uso de orientação a objetos.
A prática nos ajuda a escrever um software melhor, com mais qualidade, e um código melhor, mais fácil de ser mantido e evoluído. Esses dois pontos são importantíssimos em qualquer software, e TDD nos ajuda a alcançá-los. Toda prática que ajuda a aumentar a qualidade do software produzido deve ser estudada.
Neste livro, tentei colocar toda a experiência e tudo que aprendi ao longo desses últimos anos praticando e pesquisando sobre o assunto. Mostrei também o outro lado da prática, seus efeitos no design de classes, que é muito falada mas pouco discutida e explicada. A prática de TDD, quando bem feita, pode ser bastante produtiva. Mas, como verá ao longo do livro, os praticantes devem estar sempre alertas às dicas que o teste dará sobre nosso código. Aqui, passaremos por eles e o leitor ao final do livro terá em mãos uma nova e excelente ferramenta de desenvolvimento.
A quem se destina esse livro?
Esse livro é destinado a desenvolvedores que querem aprender a escrever testes de maneira eficiente, e que desejam aprender a como melhorar ainda mais o código que produzem. A primeira versão deste livro foi escrita em Java. Só que dado, o sucesso, decidi transformar os exemplos também em C#, para facilitar a vida de quem trabalha com a plataforma .NET.
Mas, independente de sua linguagem, toda discussão feita aqui faz sentido para outras linguagens. Mesmo que você já pratique TDD, tenho certeza que aqui encontrará discussões interessantes sobre como a prática dá feedback sobre problemas de acoplamento e coesão, bem como técnicas para escrever testes melhores e mais fáceis de serem mantidos.
Testadores também podem se beneficiar deste livro, entendendo como escrever códigos de teste de qualidade, quando ou não usar TDD, e como reportar problemas de código para os desenvolvedores.
Como devo estudar?
Ao longo do livro, trabalhamos em diversos exemplos, muito similares ao mundo real. Todo capítulo possui sua parte prática e parte teórica. Na parte prática, muito código de teste é escrito. Na parte teórica, refletimos sobre o código que produzimos até aquele momento, o que foi feito de bom, o que foi feito de ruim, e melhoramos de acordo.
O leitor pode refazer todos os códigos produzidos nos capítulos. Praticar TDD é essencial para que as ideias fiquem naturais. Além disso, a Caelum também disponibiliza um curso online sobre testes automatizados *, que pode ser usado como complemento desse livro.
Boa leitura!
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
- 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 - O que ler agora?
- 12.2 - Dificuldade no aprendizado
- 12.3 - Como interagir com outros praticantes?
- 12.4 - Códigos do Livro
- 12.5 - 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
Dados do produto
- Número de páginas:
- 198
- ISBN:
- 978-85-66250-25-1
- Data publicação:
- 05/2013