Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, com método e organização graças às boas práticas e princípios exercitados no curso anterior; mas você talvez não se sinta ainda confortável em projetar programas usando técnicas ágeis, como o desenvolvimento guiado por testes (TDD). O objetivo deste curso é expor você aos princípios e práticas de desenvolvimento guiado por testes, tanto para modelar quanto para desenvolver aplicações e componentes de software, sem abandonar os conceitos e princípios de orientação a objetos aprendidos no curso anterior. De fato, pregamos que tais conceitos e princípios fortalecem o emprego do TDD no desenvolvimento ágil de software com mais qualidade. Este curso terá um grande foco em atividades hands-on, permitindo a você captar todos os aspectos práticos da técnica e facilitar a sua aplicação quando estiver projetando e desenvolvendo software de maneira ágil nos próximos cursos. Os conceitos de desenvolvimento de software com Java apresentados neste curso incluem o seguinte: revisão de testes de unidade; automação de testes; desenvolvimento guiado por testes; ciclo do TDD; refatoração de código de produção; ciclo de refatoração; uso de objetos stubs e mocks; boas práticas no TDD; modelagem de software por meio do TDD. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar, agora usando o TDD, versões modificadas e estendidas do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Ciclo TDD no Contexto de Casos de Teste
Loading...
From the course by Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
330 ratings
From the lesson
Semana 3
Olá! Bem-vindo à Semana 3 do curso sobre TDD! Nesta semana você aprofundará seu contato prático com casos de teste e com dependências entre classes no contexto do TDD. Ao final desta semana, você será capaz de: 1) modelar casos de teste a partir de responsabilidades para uso no ciclo TDD; 2) testar classes com dependências por meio de mock objects.
Meet the Instructors
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA]
Olá bem vindo ao curso sobre TDD, eu sou o Clóvis Fernandes e hoje
iremos falar sobre o ciclo TDD no Contexto de Casos de Testes.
O TDD tem o seu ciclo que todos vocês já viram que é o
Red Green Refactor, está certo?
E esse que nós vamos mostrar é que existem dois.
Que vai fazer o ciclo nos requisitos e outro que vai
fazer o ciclo nos casos de testes definidos a partir de cada requisito.
É isso que a gente vai mostrar na aula de hoje ou seja,
ao final desta aula você terá aprendido como que funciona esse ciclo interno,
que o TDD consome os casos de teste relativos a cada dos requisitos.
Como vocês estão vendo aqui a gente tem o a modelagem
vamos dizer assim ágil, normal que a gente já tinha mostrado até agora.
A gente está vendo o ciclo TDD aqui do lado está certo?
Mas normalmente quando eu vou começar a modelagem ágil eu fiz EDUF.
EDUF é projeto suficiente, não é, está certo?
Antes de começar a fazer a modelagem ágil.
Com isso eu ao começar a modelagem ágil eu tenho
mais informações para poder fazer bom projeto ou seja, eu posso,
eu vou ter os requisitos, eu vou ter conjunto de eventuais
classes que são, através dos cartões CRC,
eu vou ter alguma arquitetura, alguma informação adicional, está certo?
Então com base nos requisitos, se eu estou usando
a modelagem CRC os meus requisitos vão ser responsabilidades.
Então eu pego cada requisito, não é, está certo?
Eu pego cada requisito, eu defino, obtenho esses requisitos todos.
E eu estou chamando aqui de req1, req2, req3 reqn.
Estou chamando esses requisitos simbolicamente desta forma.
Então eu tenho conjunto de requisitos relativo ao problema,
não precisa ser completo porque a qualquer momento pode entrar algum novo requisito,
algum requisito pode sair, esse é o jogo do TDD.
Bom, qual o próximo passo?
Eu seleciono desses requisitos.
Eu como desenvolvedor estou livre de escolher qual
requisito eu desejo, está certo?
Eu estou livre para isso, mas aqui no nosso exemplo eu
vou estar supondo que estou pegando o requisito req1, está certo,
estou supondo que estou pegando o requisito req1.
Ao selecionar, bom, vamos fazer uma suposição geral.
Se eu estou trabalhando com sistema pequeno,
eu levanto os requisitos possíveis, e posso também já
definir os casos de testes para todos os requisitos.
Projeto grande pode ser que isso não, vai levar muito tempo,
então eu posso deixar para que quando eu seleciono
o requisito nessa hora eu defino os casos de testes correspondente.
Também sem a intenção de ser completo tento ser o máximo completo,
mas ideia é fazer isso aqui rapidamente.
E é o que eu estou mostrando aí, está certo?
Eu estou mostrando aí que para o req1,
eu vou ter o caso de teste ct1 o ct2,
o ct3 e assim diante até o ctk, está certo?
O próximo, a próxima etapa é selecionar deles.
Eu também estou livre de escolher qual o caso teste eu queira usar, está certo?
Como nós mostramos lá anteriormente,
os casos testes eles são de dois tipos, não é, normalmente.
Eu olho o caminho feliz, está certo,
e olho também o caminho alternativo, ou o do teste negativo para ver se tem algum,
alguma coisa inválida, alguma entrada inválida, está certo?
É isso que eu verifico e aí pode ser que você naquele dado
momento queira por exemplo testar os dados inválidos primeiro.
Como eu estou pondo aqui simbolicamente,
esses casos inválidos podem estar no começo e você vai pegar qualquer
desses dados, você que escolhe qual que você quer usar.
Está certo?
Você pode usar válido, inválido.
e assim por diante, que vai usar dados de entrada válidos ou dados de entrada
inválidos, não tem problema.
Bom, selecionei e aí sim eu entro no ciclo TDD que era,
escreva teste para o caso de teste correspondente.
Está certo?
Ou seja, eu vou escrever teste para o JUnit com a intenção de fazê-lo
falhar e aí eu experimento e vejo ele falhar, está certo?
Algumas vezes ele pode não falhar, significa que aquele teste não está
agregando nenhuma informação adicional ao meu desenvolvimento, ao meu projeto aqui.
Bom, ele falhou agora eu vou me preocupar construir código de
produção que faça esse caso teste funcionar, está certo?
E eu faço o seguinte que eu vou então testar agora esse código
novo de produção que eu fiz, para que esse teste funcione.
Enquanto ele não funcionar eu vou mexendo nele alí.
Até o momento que funcionou.
Funcionou?
Beleza!
Aí eu vou à terceira parte do ciclo TDD que é refatorar.
No comecinho,
ou algumas vezes você faz esse ciclo e não precisa refatorar nada, está certo?
Bom, de qualquer maneira, suponha que você tenha feito a refatoração ou não você
chegou nesse ponto, e vai passar para escrever o novo teste, não é, está certo?
Para escrever o novo teste, opa, eu não posso entrar lá direto,
eu não sei qual é o caso teste para o novo teste, então eu tenho que
voltar na verdade para esse meu conjunto de casos testes,
primeira coisa que eu faço é marcar o ct1 como feito,
done, está feito, está certo?
A segunda coisa é perguntar se tem mais casos testes.
Tem mais testes?
Sim, tem mais testes.
Então eu vou para o ct2.
Do ct2 eu vou seguir todo o fluxo, não é?
Escrevo teste para ele falhar, escrevo o código de produção para ele funcionar,
vou para refatorar, pergunto se, marco ele como done,
pergunto se tem mais casos de testes e assim por diante.
Vou fazendo isso até chegar no ctk.
Então suponha que eu dei toda a volta todos eles neste meu ciclo
para cada dos casos testes cheguei no ctk, no último, não é, está certo?
que eu estava fazendo dos disponíveis nesse momento,
então passei pela refatoração, aí marco o ctk como done,
acabei de fazer isso e aí eu pergunto, tem mais testes?
Se tivesse mais testes, eu voltava para esse ciclo interno mas eu estou
já supondo que eu fui do ct1 até o ctk.
Então eu varri todos os testes do requisito 1, do req1.
Então a resposta é não, se é não o que que eu tenho que fazer?
Marcar o requisito req1 como done e é o que eu faço, marco ele como done.
E depois?
O próximo passo, escolher novo requisito.
Então o requisito pode ser por exemplo o req2 ao
escolher os requisitos nesse fluxo externo,
está certo, eu para cada deles eu vou definir os requisitos os casos de
testes correspondentes aqueles requisitos e aí eu faço o ciclo interno do TDD, que
aquele ciclo é ciclo interno relativamente aos casos testes que eu levantei.
Inclusive eu fico livre, mesmo que eu tenho marcado lá alguns casos testes,
na hora que eu estou lá fazendo o ciclo que eu apareça ou surja
novo caso teste que eu não tinha pensado.
Entra no ciclo, está certo?
Não tem problema não, está certo?
Agora quando eu volto e completei aquele requisito,
eu volto no ciclo externo para começar a consumir os requisitos eu acabei
consumindo os casos de teste para cada requisito agora eu vou mudar o
requisito e isso nós veremos na próxima aula, obrigado.
[MÚSICA]
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2019 Coursera Inc. All rights reserved.
