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.
TDD: Design Dinâmico da Aplicação
Loading...
En provenance du cours de Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
313 notes
À partir de la leçon
Semana 1
Olá, bem-vindo ao Curso 2 – Desenvolvimento de Software Guiado por Testes. Neste módulo você fará contato com os conceitos básicos de TDD. Ao final desta semana, você será capaz de: 1) entender como funciona o TDD e, principalmente, que o TDD é uma técnica poderosa de projeto e desenvolvimento de software; 2) será capaz de entender o papel fundamental da Refatoracão dentro do ciclo do TDD, permitindo a você alcançar um código de mais qualidade passo a passo e continuamente!
Rencontrer les enseignants
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 Clovis Fernandes.
Hoje, iremos dar prosseguimento à forma de projeto mais adequado, usando o TDD.
Nós estimamos que o projeto que nós estamos
chamando de Dinâmico, seja mais interessante para você desenvolver.
E o argumento não é?
Que você vai aprender ao final desta aula, é que usar uma combinação do EDUF, não é?
Que é design, Enough Design Upfront.
O design suficiente antecipadamente mais a refatoração, que é natural no TDD,
isso vai compor o que a gente está chamando de design dinâmico.
Nós havíamos mostrado, não é?
Que deve-se empregar o EDUF, não é?
O design suficiente, é, no TDD.
Por quê?
Com o BDUF, o Big Design Upfront,
há uma tendência de você deixar o sistema mais rígido,
mais inflexível para mudanças, e isso não é uma coisa muito boa.
Já, o que a gente está chamando de projeto dinâmico é
processo que vai ser mais flexível, não é?
Está certo?
E propicia que mudanças ocorram sem causar
grandes traumas a quem está desenvolvendo.
É, nós havíamos então colocado que seria bom ter EDUF,
design suficiente antes da modelagem ágil.
Por que que eu quero fazer isso?
Porque eu quero montar, estabelecer, definir com uma certa,
vamos dizer assim, uma forma de garantir que eu estou vendo
pouquinho além do que eu vou desenvolver lá na modelagem ágil.
Questões como o contexto, eu quero saber quem são os usuários,
dependendo dos usuários, os tipos de usuários, pode influenciar.
Eu quero saber quais os outros sistemas que estão envolvidos, se eu estou fazendo
sistema que usa sistemas distribuídos, coisas nuvem e assim por
diante e isso vai impactar a arquitetura do meu sistema, não é, está certo?
Então eu vou definir essa arquitetura,
como é que esses subsistemas estão combinando entre si.
E isso vai obviamente, decorrência, mostrar a,
definir alguma estrutura inicial de classes,
está certo, e a questão tembém da base de dados.
Tudo isso, todo esse, esse, esse conjunto de projeto
suficiente vai ser a entrada para a minha modelagem ágil, não é?
Está certo?
E a minha modelagem ágil que nós estamos prevendo usar aqui é principalmente
é o TDD, o desenvolvimento de software guiado por testes.
Agora abrindo, não é?
Pouco mais o que está dentro, vocês vejam que eu tenho ali os requisitos.
Eu vou usar alguma coisa daquele conjunto suficiente.
Podem ser os requisitos, eu vou usar a estrutura de classes,
mas qualquer coisa pode influenciar.
Mas basicamente eu vou usar os requisitos.
Dos requisitos normalmente eles não, eu não consigo derivar testes
direto para fazer o TDD funcionar.
Porque eu sou, eu preciso fazer teste antes.
Então o quê que eu faço?
Para cada requisito, não importa a técnica que eu esteja
usando para definir os requisitos, eu vou definir os casos de teste.
Casos de teste são os testes é, que você monta
para realmente poder usar o JUnit e aí para cada requisito você vai ter conjunto.
Nós vamos mostrar mais para frente como a gente faz isso.
Os requisitos a gente já mostrou lá no CRC, é o exemplo que a gente vai dar.
Existem outras técnicas de requisitos,
nós vamos usar por exemplo também histórias de usuário.
Mas aqui nesse curso nós vamos estar exemplificando com as responsabilidades.
De cada responsabilidade geramos alguns casos testes,
esses casos testes, e o importante que, por causa desse projeto ser suficiente,
eu não preciso ser completo porque o sistema vai funcionar, se eu esquecer
alguma coisa algum momento, eu posso refazer, mudar e assim por diante.
Bom, nesse conjunto de casos testes, aí eu escolho caso teste,
que era conjunto de casos testes para uma responsabilidade.
Eu vou começar o meu ciclo do TDD, eu faço falhar esse teste,
aí construo código de produção que vai fazer ele ser bem sucedido,
vai ficar verde, e depois se for necessário eu vou refatorar.
Se não for necessário refatorar, eu passo direto e pego o próximo caso de teste,
faço falhar e assim por diante.
Se aquele conjunto de casos de testes se esgotar,
eu pego o próximo requisito, seria a próxima responsabilidade,
defino os novos casos de testes para essa nova responsabilidade,
escolho uma delas e o ciclo recomeça.
E assim eu vou até acabar todos os requisitos que eu tenho nesse momento
ou enquanto eu estiver desenvolvendo o software, está ok?
Isso é, esses pontos que eu estou agora anotando aqui são os que eu chamo de
pontos dinâmicos, são os pontos que podem haver variações,
algumas poucas ou muitas variações.
Vocês vejam que, logo lá no começo vindo do projeto suficiente,
ali existe muita coisa que pode mudar.
Podem entrar novos requisitos, pode entrar, mudar requisitos,
eu posso mudar a arquitetura, eu posso mudar a base de dados.
Então eu posso mudar muita coisa ali, a estrutura das classes, não é?
Podem mudar.
Então ali é ponto dinâmico, é ponto que podem haver mudanças.
Lógico, se eu fiz projeto suficiente, é, pode ser que a mudança não seja tanto.
Bom, a partir disso, obtive os requisitos e, e, o ponto seguinte entre
requisitos e o caso de, os casos de testes é onde eu posso escolher os requisitos,
isso pode ter influência, por exemplo eu posso escolher a ordem dos requisitos,
os requisitos que sejam mais vamos dizer assim, fáceis de implementar ou eu
uso algum critério qualquer, diferente e eu posso escolher.
Então isso pode ser mudança.
Está certo?
Escolhendo o outro ponto de mudança é quando eu vou definir os casos
testes para aquele requisito.
Eu também vou fazer conjunto e eu posso escolher os casos testes.
Vocês vão ver exemplos mais para frente que eu vou ter
alguns critérios de como definir esses casos testes.
Depois eu posso usá-los numa ordem diferente.
Nessa hora é ponto dinâmico, eu escolho uma ordem diferente,
uma forma de escolher qual é o caso teste diferente.
O próximo ponto dinâmico é lá no, no.
no, quando eu vou fazer o código que falhou,
no meu teste eu vou fazer código que vai fazer funcionar, ser bem sucedido, não é?
E ao fazer isso eu posso escolher, geral é o que a gente chama de baby step,
eu vou fazer passos simples para construir o meu código de produção.
Mas eu poderei dados momentos ter alternativas de como construir.
Eu posso construir de jeito ou de outro, eu vou escolher.
Então é ponto que é dinâmico eu posso, dependendo da experiência do, do, do,
do desenvolvedor, ele pode escolher de jeito ou de outro, então é ponto dinâmico.
E finalmente a gente tem o, e é o mais importante, é o ponto da refatoração.
Esse é o mais dinâmico, está certo?
Esse é o mais dinâmico.
Eu vou falar mais para a frente, porque realmente é esse que é o foco que dá
dinamismo maior, desde que eu tenha projeto suficiente bem fundamentado
anteriormente e rapidamente não completo, mas razoavelmente fundamentado junto
com a refatoração, isso vai, vai fazer com que o meu código tenha mais qualidade.
E isso tudo então vai compor o que a gente chama de Projeto Dinâmico da Aplicação,
está certo?
Não é só a refatoração.
Antigamente as pessoas só olhavam dessa forma mais restrita.
Eu com a refatoração vou conseguir fazer tudo.
E aí começava a caminhar e não tinha prestado atenção alguma coisa que a gente
está agora colocando lá no EDUF, no projeto suficiente,
ou seja, a gente está olhando pouquinho mais para frente.
Então a gente otimiza isso, vai fazer uma, uso da refatoração agora pouquinho melhor.
Então essa combinação das duas coisas é importante.
por isso que a gente chama de projeto dinâmico o conjunto do que eu recebo
também lá do, do, do, do projeto suficiente.
Então agora vamos nos fixar mais no, na, no, na parte de refatoração.
Por quê?
Porque o maior impacto que vai haver na qualidade é,
e tornar o meu projeto mais flexível, é na refatoração.
Quais são as coisas que eu posso fazer na refatoração?
Eu posso fazer refatorações de dados e variáveis que eu esteja usando.
Como por exemplo, mudar o nome da variável, mudar o tipo do dado,
está certo?
Eu posso fazer a refatoração de métodos, está certo?
Métodos inclusive que podem mudar de classes,
método vai para outra classe e assim por diante.
Eu posso fazer refatoração no nível da classe, eu posso quebrar a classe
subclasses, eu posso criar superclasses da classe, eu posso pôr novos métodos,
tirar métodos dessa classe eu posso fazer monte de coisas com essa classe,
assim como eu posso fazer com a interface, com os subsistemas e a arquitetura,
ou seja, a refatoração é mais radical, porque eu posso mudar tudo.
Dependendo do meu projeto suficiente, do meu EDUF e do,
o tipo do projeto da aplicação que eu estou fazendo, se ela for uma aplicação
que é muito fluida, as pessoas não sabem direito o que querem, está certo?
Eu posso fazer uma refatoração muito grande,
incluindo inclusive a arquitetura, banco de dados e assim por diante.
O que tem que ficar claro, com o BDUF, o Big Design Up Front,
o sistema, tende a ficar mais rígido e inflexível a mudanças, isso é fato.
Se eu usar só a refatoração, eu perco aquela,
aquela antecipação de ver pouquinho à frente alguma coisa,
e eu posso estar indo direto a precipício e não estou sabendo.
Então o que é que é o certo fazer?
EDUF, que pode ser projeto suficiente que leve algumas horas,
alguns dias ou no máximo duas semanas.
O ideal, uma semana, aí no máximo duas semanas,
quando são projetos que são muito difíceis de projetar,
você tem poucas informações, nunca ninguém fez nada parecido com aquilo, está certo?
Então pode ficar difícil.
E o EDUF mais esses pontos dinâmicos principalmente com
a refatoração, aí você tem o que a gente chama de projeto emergente.
Antigamente, o projeto emergente ele não contava com o EDUF.
Agora o projeto emergente conta com o EDUF, então,
essa combinação é que torna ele muito melhor, quer dizer, o resultado final,
você vai obter sistema mais flexível e apto a mudanças,
mas com menos trauma, esse é o outro ganho que você tem.
E com mais qualidade no projeto de software, está certo?
Por isso que é importante ter essa combinação dos dois.
Algumas dessas técnicas é,
vão ser exemplificadas neste curso e nos próximos cursos.
Nós iremos exemplificar por exemplo,
usando EDUF, projeto suficiente,
baseado modelagem CRC, porque a gente já mostrou para vocês modelagem CRC.
E ela vai ser usada, pode ser usada qualquer outro tipo de requisitos.
Eu posso misturar a modelagem CRC por exemplo, com histórias de usuário,
casos de uso, não há impedimento de uma coisa.
Mais para a frente,
nós vamos dar uma ênfase no uso de requisitos baseado histórias de usuário.
Mas eu posso continuar usando a modelagem CRC para levantar as classes,
uma arquitetura inicial, as colaborações, as responsabilidades também têm utilidade,
a gente continua usando isso, mesmo trabalhando com histórias de usuário.
No nosso caso, desse curso que eu vou estar desenvolvendo a linha,
é usar requisitos baseados responsabilidades.
Na aula de hoje então, nós apresentamos que é importante você fazer
projeto dinâmico que se baseia no projeto suficiente,
a gente está chamando de EDUF, mais a refatoração, essa combinação é
que vai tornar o projeto mais dinâmico, o que a gente chama de projeto emergente.
Isso, isso é que vai ser importante.
Nós vamos exemplificar isso através de responsabilidades, cada responsabilidade,
você vai trabalhar casos de uso e aí entramos no ciclo do TDD.
E vamos até esgotar todas as responsabilidades.
Se nesse meio termo, aparecer uma responsabilidade nova, não tem problema.
Ela entra ali e aí cabe ao desenvolvedor,
colocar lá ordem de prioridade, qual que é que ele quer já trabalhar,
essa que acabou de surgir, essa responsabilidade nova, ou continua olhando
as anteriores e deixa essa nova mais para o fim, e assim por diante.
Então, o importante, é que o projeto seja dinâmico,
mas que você tenha uma perspectiva de que você vai ter início,
meio e fim mais organizado.
Obrigado!
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
