Test-Driven Development
Teste e Design no Mundo Real com PHP
Published on 23. January 2015
215 pages
978-85-5519-062-9 (ISBN)
Description
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 testa 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. 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 PHP.
Conheça todos os nossos livros em www.casadocodigo.com.br.
Neste livro, você aprenderá sobre TDD, uma das práticas ágeis de desenvolvimento de software mais populares. 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 PHP.
Conheça todos os nossos livros em www.casadocodigo.com.br.
More details
Persons
Andre Cardoso é desenvolvedor PHP, bacharelando em Análise e Desenvolvimento de Sistemas, Técnico em Informática com foco em desenvolvimento de sistemas Web-based. Trabalha exclusivamente com PHP há cerca de 5 anos e durante este período esteve envolvido em projetos de todos os portes para grandes clientes como HSBC, Renault e Liquigás. Também desenvolveu sistemas para inúmeras startups nos estados do Paraná, Santa Catarina e São Paulo. Antes do PHP, aventurou-se com Java, um pouco de .Net e Delphi, mas foi no PHP que decidiu focar e especializar-se. Atualmente, trabalha na empresa Redsuns Tecnologia em Curitiba que tem foco em soluções tecnológicas inteligentes e desenvolvimento de startups. Ministrou palestras e workshops sobre TDD, PHP e tecnologias que o complementam nos eventos SFD (Software Freedom Day), FTSL (Fórum de Tecnologia em Software Livre) e FLISOL (Festival Latino Americano de Instalação de Software Livre). Tem uma enorme satisfação como profissional em compartilhar conhecimento e faz isso participando de diversos grupos de discussões e alguns projetos open source.
Maurício é instrutor e desenvolvedor da Caelum, possui mais de 9 anos de experiência de desenvolvimento de softwares, tendo participado de projetos para grandes empresas nacionais e internacionais. Mauricio é também mestre em Ciência da Computação pela Universidade de São Paulo (USP), onde pesquisa sobre TDD e sua influência no design de sistemas orientados a objetos. Atualmente, é aluno de doutorado pelo mesmo instituto. Palestrante em eventos nacionais e internacionais, com destaque para sua apresentação no 1º Workshop Internacional sobre Test-Driven Development, localizado em Paris, no ano de 2010, Agile Brazil 2010, 2011 e 2012, e QCON SP 2010 e 2012. Mauricio gosta de discutir sobre TDD, melhores práticas e princípios de orientação a objetos, métodos ágeis de desenvolvimento de software e linguagens de programação. Está no Twitter como @mauricioaniche .
Maurício é instrutor e desenvolvedor da Caelum, possui mais de 9 anos de experiência de desenvolvimento de softwares, tendo participado de projetos para grandes empresas nacionais e internacionais. Mauricio é também mestre em Ciência da Computação pela Universidade de São Paulo (USP), onde pesquisa sobre TDD e sua influência no design de sistemas orientados a objetos. Atualmente, é aluno de doutorado pelo mesmo instituto. Palestrante em eventos nacionais e internacionais, com destaque para sua apresentação no 1º Workshop Internacional sobre Test-Driven Development, localizado em Paris, no ano de 2010, Agile Brazil 2010, 2011 e 2012, e QCON SP 2010 e 2012. Mauricio gosta de discutir sobre TDD, melhores práticas e princípios de orientação a objetos, métodos ágeis de desenvolvimento de software e linguagens de programação. Está no Twitter como @mauricioaniche .
Content
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 Por que prefixo test e sufixo Test?
6.4 Test Data Builders
6.5 Testes repetidos
6.6 Escrevendo boas asserções
6.7 Testando listas
6.8 Separando as classes de teste
6.9 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 E quanto ao código legado?
12.3 Dificuldade no aprendizado
12.4 Como interagir com outros praticantes?
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
Bibliografia
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 Por que prefixo test e sufixo Test?
6.4 Test Data Builders
6.5 Testes repetidos
6.6 Escrevendo boas asserções
6.7 Testando listas
6.8 Separando as classes de teste
6.9 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 E quanto ao código legado?
12.3 Dificuldade no aprendizado
12.4 Como interagir com outros praticantes?
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
Bibliografia
