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.
Mitos e Lendas sobre TDD
Loading...
来自 Instituto Tecnológico de Aeronáutica 的课程
TDD – Desenvolvimento de Software Guiado por Testes
330 个评分
从本节课中
Semana 2
Olá! Bem-vindo à Semana 2 do curso sobre TDD! Nesta semana você aprofundará seu contato prático com o TDD, bem como com o ciclo de Refatoração. Ao final desta semana, você será capaz de: 1) modelar uma classe com o TDD, entendendo os princípios que estão por trás; 2) entender o papel do mau cheiro" no Ciclo da Refatoração!
与讲师见面
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá a todos!
Meu nome é Eduardo Guerra,
esse é o curso de desenvolvimento de software guiado por testes.
Hoje vamos falar sobre mitos e lendas sobre TDD, certo?
Então eu vejo que muito se fala sobre TDD e muita besteira é falada sobre TDD.
Então hoje vamos pegar desses mitos aí e vamos falar pouquinho
sobre eles para que você possa, você como, espero que novo desenvolvedor que vai
adotar essa técnica no seu dia a dia, que você possa,
saiba responder quando alguém chegar com algumas dessas dúvidas.
Pode ser que você já tenha ouvido falar disso,
que você mesmo tenha essa dúvida ou você mesmo tenha essa concepção errada do TDD,
então vamos falar pouquinho mais sobre isso nessa aula.
Então como eu falei existem aí muitas histórias sobre TDD,
só que, será que elas são verdade?
Todas elas?
Então hoje vamos fazer aqui papel aí dos Mythbusters, certo?
Os caçadores de mitos e vamos falar pouco aí sobre algumas dessas coisas
que se falam sobre TDD que não são verdade ou às vezes não são 100 por cento verdade.
Então vamos começar aqui com nosso amigo saci-pererê ou melhor saci-TDD,
essa piada foi do Clovis, dei o crétido hein Clovis.
Que ele está falando o quê?
Que o TDD sempre usa testes de unidade.
Bom, na verdade a grande parte dos
testes do TDD acaba sendo, a gente acaba usando o mesmo teste de unidade,
mas não quer dizer que sempre o TDD tenha que utilizar testes de unidade.
Muitas vezes a gente faz o TDD cima de teste de integração,
cima de testes de componente.
Porque é que o teste de unidade é muito utilizado?
Quando você separa uma classe do resto do sistema para poder testar ela,
usando algumas técnicas como smoke objects,
que a gente vai ver ainda nesse curso nas próximas aulas.
A gente acaba desacoplando as classes, ou seja,
se eu consigo isolar uma classe para testar ela,
então eu consigo encaixar ela mais fácil vários contextos, então o
simples fato de eu forçar que seja o teste de unidade isso pode me trazer benefícios.
Só que nada impede de de repente a gente vai discutir isso durante esse curso,
de às vezes querer pegar e fazer o TDD desenvolvendo por exemplo,
grupo de classes.
O que é importante se você for fazer isso, é você manter aquele ritmo
alternando entre o código de teste e o código de produção,
você manter aquele baby steps, ou seja, você conseguir alternar de para o outro.
O grande problema de às vezes você fazer o TDD encima de várias classes, é que às
vezes você cria teste e aí você demora a implementar para poder voltar nesse teste,
ou seja, para fazer pequeno teste passar você tem que fazer muita coisa.
Então é esse cuidado que você tem que ter quando você está fazendo o TDD testes
que tenham escopo maior que o teste de unidade,
agora se você consegue manter esse ritmo, sem problema nenhum.
Bom vamos ver o que é que a próxima lenda aí tem a nos dizer.
Quem é essa figura aí?
É o caipora, certo?
Então ele fala o seguinte: olha TDD não é criar o teste antes?
Então eu vou lá, vou criar todos os testes da classe, certo?
E depois vou implementar.
E aí se eu fizer isso eu estou fazendo o TDD?
Está certo isso?
Errado!
No TDD é importante, faz parte da técnica TDD você
avançar pequenos passos e trabalhando teste por vez.
Às vezes se você tem, eu não gosto de ser muito pragmático ou melhor,
dogmático, tem que ser desse jeito, tem que ser.
Eu sou mais pragmático,
ou seja, vamos focar aqui na prática, vamos ver como que funciona melhor.
Então às vezes você tem poxa,
ao invés de criar teste eu crio dois que são relacionados e aí eu vou faço uma
implementação que vai atender aqueles dois testes ao mesmo tempo, ok.
Se eu conseguir manter o meu baby step está perfeito.
Agora você ir lá e criar monte de testes e depois ficar duas horas
trabalhando na sua classe, isso definitivamente não é TDD.
Essa alternância entre o código de testes e o código de produção é
extremamente importante para que o TDD dê aqueles benefícios que ele têm.
Então se você for adaptar, criar mais teste e etc.
tenha mente que é importante você ter esse ritmo.
Outra coisa que eu já escutei é:!
Eu faço TDD, faço monte de testes, então meu código ele é
à prova de erros, você pode procurar alí que não vai ter nenhum bug.
E eu já vi o contrário também, do tipo:!
Achei bug aqui, mas você não estava fazendo TDD?
Essa técnica não é boa?
isso aí não deixa o código à prova de erros?
Então vamos ver o que a gente tem a dizer sobre esses mitos aí, não é?
Aí então!
Fiz usando TDD eu "agarantio", não é?
Igual lá ao seu Creisson não é?
Não isso não é verdade.
O TDD ele pode ajudar a prevenir muitos erros e é verdade,
quando você faz o teste você, várias coisas às vezes que você iria errar
você acaba não errando, mas ele não garante que não pode ter algum erro.
Então vou dar alguns exemplos aqui de erros que podem acontecer quando a gente
está usando o TDD.
Então por exemplo, vamos supor que é algum caso especial,
você esqueceu de criar teste para aquilo.
Vamos supor, você está fazendo ali uma classe de cálculo e você
não criou nenhum teste que testava com valor menor do que 0 por exemplo.
Então se alguém chamar aquilo ali pode dar erro porquê?
Porque você não fez aquele teste.
Você pode ter feito o teste errado,
você pode ter feito uma verificação errada, porque o teste ele
também pode ter erros nele, ele pode não estar verificando aquilo que você quer.
Eu já vi isso acontecer, às vezes você achou que criou o teste
correto mas ele não está verificando, você se esqueceu de colocar assert,
e ele não está verificando alguma coisa ou pode ser também que você você não entendeu
o requisito direito e aí você criou teste que verificava uma outra coisa e você fez
uma classe que atendia aquela outra coisa, ou seja, o teste, a classe está fazendo
aquilo que você queria que ela fizesse, só que aquilo que você entendeu que era para
ela fazer não era o que ela tinha que fazer dentro do contexto do sistema.
Então pode ter tido erros, então assim, o fato de você fazer TDD ajuda sim,
a diminuir a quantidade de erros, têm vários estudos que mostram isso,
que fazer TDD diminui a quantidade de erros,
mas também não garante que seu código vai ser à prova de erros.
E aí você pergunta: mas o que é que eu faço se de repente
eu achar erro no meu código onde eu fiz TDD?
Que é que você vai fazer?
Você vai lá, vai criar teste que tenha aquele erro,
que pegue aquele cenário.
Então lembra que para a gente continuar o TDD,
para a gente continuar no ciclo do TDD, o teste ele não pode passar,
ele tem que ser teste que dá problema, não que dá problema,
mas que a classe não passe naquele teste e a partir dali você continua fazendo o TDD.
Quando você conseguir criar teste que fale,
que pegue aquele cenário onde está o problema,
aí é fácil, é só você continuar o TDD e se dali você vê que tem outro problema você
vai seguindo a ideia do TDD, criando outros testes, talvez
com cenários relacionados que talvez possam não estar funcionando, certo?
Próximo mito!
Agora é o, que bicho é esse?
Acho que é o Caipora, certo?
Já vi muita gente falar assim, ai esse negócio de TDD é meio esquisito,
porque é muito suspeito que o desenvolvedor teste o seu próprio código,
como se fosse ser teste tendencioso, o fato do desenvolvedor
testar o próprio código, deveria ser outra pessoa que faria isso.
Então o que a gente tem a dizer a respeito disso?
Que existem diferentes tipos de teste.
Os diferentes tipos de teste eles têm diferentes objetivos.
O teste que a gente faz no TDD, que pode ser teste de unidade,
integração como a gente viu, é teste para o desenvolvedor,
para dar feedback para o desenvolvedor,
para ele verificar se aquele código está fazendo o que ele quer que faça.
É erro comum,
às vezes a gente faz o código achando que ele vai funcionar tais cenários,
que ele vai fazer determinadas coisas, só que ele não faz aquilo que a gente quer.
Então o teste que a gente faz no TDD é para isso,
é para ver se o teste Faz o que o desenvolvedor quer que ele faça.
Tá? Então é teste mais baixo nível, ali.
Tá? Os testes do TDD não eliminam os testes
que a gente chama de teste de aceitação, certo?
Que é onde o cliente vai validar se aquilo que foi implementado tá de
acordo com as necessidades dele.
Então, uma coisa é o desenvolvedor ver se aquilo que ele fez é-- aquilo
que ele queria era o que ele implementou, e outra coisa é ver se aquilo que ele
implementou é o que o cliente precisava; tá de acordo com os requisitos do cliente.
Então, esse é o teste de aceitação.
Aquele teste, lá, do TDD, ele ajuda a tirar vários tipos de bug,
mas depois você ainda tem que validar se aquilo que você fez é
realmente o que o cliente precisava, é realmente o que o cliente queria.
Certo?
Bom, vamos-- que bicho é esse?
Alguém sabe que bicho é esse?
Ó, tem uma pista aí no que ele tá segurando.
Sabe qual que é?
É o chupa-cabra!
Que que o chupa-cabra tá falando pra gente, tá?
Se eu criar teste depois, eu já não tô fazendo TDD.
Tá?
Imagina lá, você tá lá programando, tranquilo, fez teste, implementou, passou.
Fez teste, implementou, passou.
E você falou: "Opa, peraí, eu criei avancei pouquinho mais e já vou
criar teste aqui pra ver se aquilo funciona".
Aí passa o cara lá "A-haaa!
Peguei você!
Você não tá fazendo TDD!
Peguei você fazendo teste depois!".
Aí, né, você chega lá: " o TDD vem sendo feito há séculos dessa forma!".
É uma blasfêmia você ir lá e criar, né, o teste,
uma vez, né, de vinte testes que você tá criando,
deles você criou primeiro o código e depois o teste.
Isso é uma blasfêmia!
Né? Nada disso, né, o TDD não é dogma.
Tá? Não é uma coisa amarrada.
Você tem que fazer ele da forma que funciona pra você,
da forma que vai ser mais produtivo, tá?
Então, tá OK às vezes você ir lá e criar
pouquinho da funcionalidade antes de criar o teste.
Às vezes você fala assim: " tô implementando aqui,
já fiz o-- já fiz aqui o caso aqui pra tantos.
Ó, se eu criar mais esse 'if' aqui, eu já consigo resolver esse outro caso".
Aí você já adiciona lá e aí você,
por exemplo, vai lá no teste e já adiciona aquele novo teste.
Tá? Então,
o importante é também você não cair na tentação e ir lá e fazer todo o
código de produção e aí depois ir fazer todos os testes, né?
Se você mantiver aquele ritmo de alternância entre teste e código de
produção, não tem problema às vezes você ir lá, né,
e fazer o código de produção desde que dali a pouco você vá lá e já crie o teste
que verifique aquilo pra você continuar nesse ritmo de alternância.
Tá certo?
Então, com isso daí, assim, quero abranger
outras questões também, tá, que a gente ensina aqui a técnica,
né, mas a gente não precisa ser dogmático relação a ela, né?
" desviou pouquinho ali, já tá tudo errado".
Não, vamos fazer da forma que funciona, vamos manter o ritmo,
certo, pra gente ganhar os benefícios da técnica, mas a gente não precisa, né,
ser completamente, né, dogmático,
ali, né, sem, sem-- não pode olhar pouquinho pro lado que tá errado.
Tá? Relação a isso eu queria fazer meio que
"disclaimer" aqui, né, eu acho assim, eu acho que as técnicas tão aí
pra gente poder aprender e usar elas da melhor forma possível.
Tá? Não vai falar assim: "
o Guerra falou que pode criar depois!".
Aí vai lá, vai criar tudo depois.
Não. Então, assim,
antes de adaptar uma técnica, tenha, tenha certeza de que você aprendeu ela,
que você compreendeu o funcionamento dela e que você
tá ciente das consequências daquela mudança que você tá fazendo.
Então, apesar de eu ter falado isso agora, né, tente fazer o TDD mais quadradinho,
né, principalmente agora no começo, que a gente tá praticando,
que a gente tá aprendendo e aí depois que você ganhar a prática, aí sim,
você vai e pode adaptar e pode colocar o seu toque pessoal ali; isso não
vai ter nenhum problema, não vai deixar de ser TDD e etc.
porque você foi lá e faz aquilo pouquinho diferente,
criou teste depois ali uma vez ou outra, isso daí não tem problema.
Mas, assim, só abro esse parêntese pra dizer pra vocês: tentem agora, né,
nos exercícios, fazerem mesmo o TDD do jeito mais quadradinho,
por mais que tenha uma dificuldade.
Depois que você tiver prática na técnica, aí sim, você vai e faz as suas adaptações.
Tá certo?
Então, espero que, com essa aula aqui, eu tenha conseguido desmistificar
alguns mitos, algumas lendas, aí, sobre TDD, certo?
Espero que tenha ficado claro.
Se você ainda tem alguma dúvida, mande aí no fórum que a gente vai ter
prazer responder, né, acredito que talvez os próprios colegas aí,
né, têm participado bastante, podem responder pra você também.
Muito obrigado, até a próxima aula.
[MÚSICA]
