O documento discute Test Driven Development (TDD), incluindo seus princípios, tipos de testes, boas práticas e ferramentas. TDD envolve escrever testes automatizados antes de escrever código funcional e usá-los para guiar o desenvolvimento de software.

1. Test Driven Development
Jony Santos
https://www.linkedin.com/in/jonyfs

2. Agenda
O que é?
Princípios
Tipos de Testes
Unit Testing
Boas práticas
Ferramentas
“Desculpability”
Case
Conclusões

3. O que é?
● técnica de desenvolvimento
● ciclo curto de repetições
○ desenvolvedor escreve um caso de teste
automatizado
○ Produz código que possa ser validado
pelo teste
○ Refatoramento de código

4. Simples assim!
CodificaçãoTeste Refatoramento

5. Quando surgiu?
● 1999 - Extreme Programming (XP)
○ Valores fundamentais
■ comunicação
■ simplicidade
■ feedback
■ coragem
■ respeito

6. XP - Principios Básicos
● feedback rápido
● presumir simplicidade
● mudanças incrementais
● abraçar mudanças
● trabalho de qualidade

7. TDD - Princípios
● TDD está muito relacionado ao design de
software
● Gera confiança
● Possibilita mudanças
● É automático
● Valida o Design do Software
● É uma documentação viva através de
exemplos
● Feedback rapido
● Qualidade na implementação
1

8. TDD - Princípios
● Qualidade de Design
● Força constante integração da equipe
● Requer mais disciplina
● Força a profissionalização no
desenvolvimento de software
● Não são apenas testes, é a nossa
dependência
● Desenvolvedores escrevem os testes
● Através dos testes se chega ao código
● Pequenas iterações de desenvolvimento
2

9. TDD - Princípios
● TDD ajuda a:
○ produzir código limpo
○ escrever teste de código
○ escrever o código funcional
○ refatorar código
○ Documentar o código
3

10. ● F (Fast)
● I (Isolated)
● R (Repeateble)
● S (Self-verifying)
● T (Timely)
F.I.R.S.T.

11. Tipos de Testes
● Unitário - TDD está aqui
● Integração
● Interface
● Regressão(Integração Contínua)
● Sistema
● Performance
● Estresse
● Usabilidade

12. TDD - Unit Testing
Execute o
teste e
observe
Adcione
um teste
Escreva
o código
Execute
os testes
automati
zados
Refatore
o código
Unit Test

13. Boas Práticas
Overview

14. Boas Práticas
● Aclopamento - baixo nivel de acoplamento
● Coesão - poucas responsabilidades
● Injeção de Dependência (DI)
● Inversão de Controle (IOC)
● Responsabilidade Única
● Simplicidade
● Principio Aberto/Fechado(Open-Closed
Principle / OCP)

15. Boas Práticas
● A lei de Demeter (LoD)
● Modularização
● DDD
● Clean Code
● Duplicação - Evitar!

16. Arquitetura e Design

17. Arquitetura e Design
● TDD não substitui arquitetura e design
● TDD irá informar e validar(ou invalidar) as
decisões de design
● TDD praticamente irá descobrir fraquezas e
falhas no design do projeto. Preste atenção
nisso

18. Ferramentas

19. Ferramentas
● .NET - NUnit
● Java - JUnit / TesteNG
● PHP - PHPUnit / SimpleTest
● Javascript - Jasmine
● C - CUnit
● Python - PyUnit
● Delphi - DUnit
● JavaFx - JemmyFx

20. habilidade de
afastar de si a
responsabilidade,
culpando os outros
ou as
circunstâncias por
aquilo que não saiu
como esperava
Desculpability

21. - Isto funcionava bem até
ontem.
- Isto nunca aconteceu antes.
- Isto nunca vai acontecer.
- Isto não deveria ter
acontecido.
- O que? Como isto é possível?
- Isto deve ser um problema
com o seu hardware.
- Confessa. O que você digitou de
errado para travar?
- Este pode não ser o código que
eu fiz.
- Eu não mexo neste código há
semanas!
- Alguém deve ter alterado meu
código.
- Verdade. Isto é muito
estranho…
- Você deve estar rodando a
versão errada.
- É apenas uma coincidente
falta de sorte.
- Você tem de concordar é
impossível testar todas as
possibilidades.
- Na realidade os dados que
você utilizou estão fora de uso.
- Isto funciona, mas nunca
havia sido pensado.
- Onde você estava quando o
programa estava funcionando?
- Você verificou se não tem um
vírus no seu computador.
- Porque você quer fazer isto
logo desta maneira.
- Tudo bem, mesmo que não
Desculpability
● Eu não tenho tempo para isto!
● Sou pago apenas para desenvolver
software. Não sou pago para
testar.
● Eu dou suporte a uma aplicação
legada
● A Equipe de Testes e o próprio
usuário da aplicação são os
melhores para encontrar bugs
● Eu não sei como criar testes
unitários ou eu não sei como
escrever bons testes.

22. Case

23. Documentação de API
através de Testes de Integração
● Credit Card API - https://github.com/jonyfs/credit-card-api
● Spring Boot
● Embedded MongoDB
● HATEOAS
● Spring REST Docs
● AsciiDoctor
● Integração Contínua
● Deploy Contínuo - https://creditcardapi.herokuapp.com/api

24. Conclusões