TDD Desenvolvimento orientado ao teste

TDD
Desenvolvimento orientado a
teste
O QUE É TDD? TDD é uma técnica de automação dos
testes, onde nenhum código de produção
é escrito sem antes se escrever um
teste para ele.
Objetivos
Detecção de falhas e defeitos antes
de disponibilizar em produção
Verificação do correto funcionamento
de uma aplicação
Qualidade do código
IMPACTOS DA
FALTA DE
TESTES Retrabalho
Maior números de ticket no dia de
uma atualização do sistema
Insegurança no código realizado
Prejuízo à imagem da equipe
PONTOS
POSITIVOS DO
TDD
Qualidade do código
Um dos principais ensinamentos, senão o
principal, do TDD é que se algo não é
possível de ser testado então foi
desenvolvido de forma errada.
Raciocínio
Para se criar o teste antes do
desenvolvimento é dispensado um tempo
maior na lógica da funcionalidade e seu
funcionamento, forçando o desenvolvedor
a encarar o código de outra maneira.
Segurança
Maior segurança da equipe e do
desenvolvedor no código que será
entregue.
COMO
COMEÇAR
ciclo
COMO
COMEÇAR
Vermelho
Escrita do primeiro teste antes mesmo da
lógica existir. Este teste é feito para
falhar.
Verde
Escrever um código para que o teste passe.
Esta lógica deve ser desenvolvida da
forma mais simples possível eliminando
complexidades desnecessárias fazendo com
que a evolução do código ocorra de forma
segura.
Refatorar
Melhoria do código. Neste ponto são
removidas duplicações, múltiplas
responsabilidades e o código fica cada
EXEMPLO
PRÁTICO
EXERCÍCIO:
Retornar o N-ésimo número de
Fibonacci.
N-ésimo número de Fibonacci é obtido
pela soma dos dois números anteriores
da sequência, sendo que o primeiro
número é 0 e o segundo é o 1. Sendo
assim:
o terceiro é 1 (0 + 1)
o quarto é 2 (1 + 1)
assim por diante.
EXEMPLO
PRÁTICO
1)Escrevendo o teste (red)
Por definição o primeiro número de
Fibonacci é zero (Fibonacci(0) = 0).
Abaixo descrevemos o teste que atende
a esta especificação
Este é o passo red, como estamos desenvolvendo o
teste primeiro o método nem existe ainda, mas já
estamos pensando em como ele deve funcionar.
EXEMPLO
PRÁTICO
2) Fazendo o teste passar (green)
Neste momento você fará o código mais
simples para que o teste passe ou
seja, fazer o método retornar 0.
EXEMPLO
PRÁTICO
3) Refatorar (refatorar)
Neste momento o código está
funcionando e não tem como ficar mais
limpo. Mas obviamente não está pronto.
A partir daí siga o desenvolvimento do
método
CONSTANTES E
BABY STEPS
Retornar constantes e baby steps,
obviamente, não são regras imaculadas
do TDD. Conforme você for adquirindo
experiência e segurança em seguir
adiante, alguns passos podem ser
pulados, inclusive começando por uma
implementação mais próxima da solução
final.
DEVO USAR O TDD EM 100% DO MEU
CÓDIGO?
NÃO!!
Se estamos, por exemplo, escrevendo a implementação de um DAO
(classe que se comunica com o banco de dados), talvez escrever os
testes antes não vá ajudar tanto, afinal não há grandes decisões de
design a serem tomadas em classes como essa, e a funcionalidade
tende a ser simples. Escrever o teste depois, portanto, não será
tão diferente de escrever o teste antes.
1 de 13

Recomendados

TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)Renato Groff
3.8K vistas37 diapositivas
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven DevelopmentElias Nogueira
7.9K vistas45 diapositivas
Tdd and bddTdd and bdd
Tdd and bddMohamedSubhiBouchi
314 vistas12 diapositivas

Más contenido relacionado

La actualidad más candente

Manual de osloManual de oslo
Manual de osloAndré Ott
6.2K vistas184 diapositivas
Test Automation PyramidTest Automation Pyramid
Test Automation PyramidT. Alexander Lystad
4.7K vistas21 diapositivas
Testes de SoftwareTestes de Software
Testes de SoftwareCapgemini
3.2K vistas31 diapositivas
Apresentação CMMiApresentação CMMi
Apresentação CMMiFabio Barnes
1.7K vistas46 diapositivas

La actualidad más candente(20)

Manual de osloManual de oslo
Manual de oslo
André Ott6.2K vistas
Test Automation PyramidTest Automation Pyramid
Test Automation Pyramid
T. Alexander Lystad4.7K vistas
TDD and Unit Testing in GolangTDD and Unit Testing in Golang
TDD and Unit Testing in Golang
Sofian Hadiwijaya1.6K vistas
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
Manoel Pimentel Medeiros8.4K vistas
Testes de SoftwareTestes de Software
Testes de Software
Capgemini3.2K vistas
Apresentação CMMiApresentação CMMi
Apresentação CMMi
Fabio Barnes1.7K vistas
An Introduction to Test Driven Development An Introduction to Test Driven Development
An Introduction to Test Driven Development
CodeOps Technologies LLP13.9K vistas
Princípios S.O.L.I.D.Princípios S.O.L.I.D.
Princípios S.O.L.I.D.
Leandro Nishijima499 vistas
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
Rondinelli Mesquita2.8K vistas
Test-Driven DevelopmentTest-Driven Development
Test-Driven Development
John Blum1.2K vistas
Apresentação mvcApresentação mvc
Apresentação mvc
leopp1.8K vistas
Palestra Gestão da Inovação.Palestra Gestão da Inovação.
Palestra Gestão da Inovação.
innoscience_5.8K vistas
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de Software
Bruno Bitencourt Luiz9.6K vistas
Aula 22 e 23 - Artefatos   parte 1 e 2Aula 22 e 23 - Artefatos   parte 1 e 2
Aula 22 e 23 - Artefatos parte 1 e 2
Orlando Lima Treinamentos256 vistas
Why unit testinglWhy unit testingl
Why unit testingl
Priya Sharma1.8K vistas

Similar a TDD Desenvolvimento orientado ao teste

UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27Hélio Medeiros
325 vistas30 diapositivas
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"thiagobapt
1.1K vistas140 diapositivas
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidadesSimone Pittner
545 vistas11 diapositivas

Similar a TDD Desenvolvimento orientado ao teste(20)

Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
Dextra Sistemas / Etec Itu428 vistas
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
Hélio Medeiros325 vistas
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"
thiagobapt1.1K vistas
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
Simone Pittner545 vistas
Teste automatizados e tddTeste automatizados e tdd
Teste automatizados e tdd
Luiz Fernando Signorelli108 vistas
RealDay: Introduction to TDDRealDay: Introduction to TDD
RealDay: Introduction to TDD
Miguel Schmitz Grazziotin539 vistas
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
Eduardo Carvalho909 vistas
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Thiago Faria de Andrade1.6K vistas
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
Dionatan default1.4K vistas
TDD direto das trincheirasTDD direto das trincheiras
TDD direto das trincheiras
Luiz Borba314 vistas
TDDTDD
TDD
João Victorino392 vistas
Testes de unidade - Conhecendo e aplicandoTestes de unidade - Conhecendo e aplicando
Testes de unidade - Conhecendo e aplicando
André Phillip Bertoletti474 vistas
Coding Dojo - FuncionamentoCoding Dojo - Funcionamento
Coding Dojo - Funcionamento
thiagodp376 vistas
Lightning talk Test-Driven Development - TDDLightning talk Test-Driven Development - TDD
Lightning talk Test-Driven Development - TDD
Willians De Paula Pereira520 vistas

TDD Desenvolvimento orientado ao teste

  • 2. O QUE É TDD? TDD é uma técnica de automação dos testes, onde nenhum código de produção é escrito sem antes se escrever um teste para ele. Objetivos Detecção de falhas e defeitos antes de disponibilizar em produção Verificação do correto funcionamento de uma aplicação Qualidade do código
  • 3. IMPACTOS DA FALTA DE TESTES Retrabalho Maior números de ticket no dia de uma atualização do sistema Insegurança no código realizado Prejuízo à imagem da equipe
  • 4. PONTOS POSITIVOS DO TDD Qualidade do código Um dos principais ensinamentos, senão o principal, do TDD é que se algo não é possível de ser testado então foi desenvolvido de forma errada. Raciocínio Para se criar o teste antes do desenvolvimento é dispensado um tempo maior na lógica da funcionalidade e seu funcionamento, forçando o desenvolvedor a encarar o código de outra maneira. Segurança Maior segurança da equipe e do desenvolvedor no código que será entregue.
  • 6. COMO COMEÇAR Vermelho Escrita do primeiro teste antes mesmo da lógica existir. Este teste é feito para falhar. Verde Escrever um código para que o teste passe. Esta lógica deve ser desenvolvida da forma mais simples possível eliminando complexidades desnecessárias fazendo com que a evolução do código ocorra de forma segura. Refatorar Melhoria do código. Neste ponto são removidas duplicações, múltiplas responsabilidades e o código fica cada
  • 7. EXEMPLO PRÁTICO EXERCÍCIO: Retornar o N-ésimo número de Fibonacci. N-ésimo número de Fibonacci é obtido pela soma dos dois números anteriores da sequência, sendo que o primeiro número é 0 e o segundo é o 1. Sendo assim: o terceiro é 1 (0 + 1) o quarto é 2 (1 + 1) assim por diante.
  • 8. EXEMPLO PRÁTICO 1)Escrevendo o teste (red) Por definição o primeiro número de Fibonacci é zero (Fibonacci(0) = 0). Abaixo descrevemos o teste que atende a esta especificação Este é o passo red, como estamos desenvolvendo o teste primeiro o método nem existe ainda, mas já estamos pensando em como ele deve funcionar.
  • 9. EXEMPLO PRÁTICO 2) Fazendo o teste passar (green) Neste momento você fará o código mais simples para que o teste passe ou seja, fazer o método retornar 0.
  • 10. EXEMPLO PRÁTICO 3) Refatorar (refatorar) Neste momento o código está funcionando e não tem como ficar mais limpo. Mas obviamente não está pronto. A partir daí siga o desenvolvimento do método
  • 11. CONSTANTES E BABY STEPS Retornar constantes e baby steps, obviamente, não são regras imaculadas do TDD. Conforme você for adquirindo experiência e segurança em seguir adiante, alguns passos podem ser pulados, inclusive começando por uma implementação mais próxima da solução final.
  • 12. DEVO USAR O TDD EM 100% DO MEU CÓDIGO?
  • 13. NÃO!! Se estamos, por exemplo, escrevendo a implementação de um DAO (classe que se comunica com o banco de dados), talvez escrever os testes antes não vá ajudar tanto, afinal não há grandes decisões de design a serem tomadas em classes como essa, e a funcionalidade tende a ser simples. Escrever o teste depois, portanto, não será tão diferente de escrever o teste antes.

Notas del editor

  1. Como o método ainda não foi implementado ele falhará. RED