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.
Exemplo de Definição de Casos de Teste de Responsabilidades do SAB
Loading...
En provenance du cours de Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
315 notes
À partir de la leçon
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.
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 Clovis Fernandes.
E hoje iremos mostrar uma forma,
exemplo de definição de casos de teste, de uma forma mais prática,
que vai ser cima do SAB, o sistema de automação de biblioteca
que nós mostramos uma modelagem CRC, no curso anterior.
Então, a ideia aqui então, é definir os casos testes com
base nas responsabilidades que nós já identificámos no SAB.
Essa é a ideia, nós vamos exemplificar usando uma responsabilidade
da classe biblioteca, que é o Empresta livro,
então, obviamente, vocês estão vendo que a classe biblioteca,
tem várias responsabilidades, nós podemos trabalhar até mais sobre esse material,
então, vamos trabalhar agora aqui no empresta livro.
Porque ele é vamos dizer assim ele é fundamental para o caso da biblioteca que
é o ato de você emprestar, o outro seria o devolver, são as duas mais importantes.
Então o empresta livro é o que nós vamos olhar.
Ele é uma responsabilidade, eu vou olhar isso como se fosse requisito,
então se eu estivesse listando os meus requisitos eu ia chamar de requisito 1, 2,
3 assim os que eu acho mais importantes para começar a trabalhar e o requisito
empresta livro, ele para mim ele é o requisito primeiro para fazer, está certo?
Mas a gente fica livre, cada fica livre de escolher qual que seria o
requisito importante para aquele momento.
Nesse momento para mim, é o requisito 1, é o empresta livro.
Eu sei que ele é da classe biblioteca e ele foi, vamos dizer assim,
incorporado num método chamado empresta livro que é bem
próximo do nome da responsabilidade, não é, está certo?
E com dois parâmetros, o parâmetro livro e o parâmetro usuário,
ou seja eu empresto o livro para usuário, é isso que a gente está pensando fazer.
Obviamente, nós vamos definir aqui, exemplificar a definição
de casos testes com base nas responsabilidades.
Nós vamos então seguir aquele padrão que já foi mostrado anteriormente material
de leitura, que nós mostramos como se
define os casos testes quando você está querendo transformar
ele código do JUnit para ser testado, não é, está certo?
Então você usa duas características, uma é a do caminho feliz e o outro é o,
caminho feliz onde todos os dados de entrada,
ou que são considerados apropriados para aquele contexto,
são válidos e o caminho que a gente chama de negative testing,
ou caminho alternativo, que alguns desses dados de
entrada ou de contexto são inválidos, está certo?
No caso aqui eu tenho o ct1.
O ct1, nesse caso do caminho feliz, o livro e o usuário são
válidos o ct1 eu tenho: empresto o livro ao usuário, está certo?
Que o livro, ai,
os dados de entrada são livro válido, usuário válido.
Então, o meu caso teste, sempre quando eu coloco entre colchetes é o meu caso teste,
ou seja, eu estou derivando desse, do ct1,
que é empresta livro ao usuário,
que o livro e o usuário são válidos, eu vou criar caso teste.
Então a entrada é livro e usuário válido e eu espero
que ao emprestar o livro, no nosso sistema,
aquele livro ele se torna indisponível, ele pode ter várias cópias,
mas aquela cópia se torna indisponível para ser emprestada para outros usuários.
Então, nessa hora o livro eu espero que ele se torne indisponível.
Quando eu fizer o código real, não é, está certo?
O livro tem que se tornar realmente indisponível, ou seja, o que eu esperava
que é livro indisponível e o real que aconteceu do livro ser indisponível mesmo.
Ok, eles coincidiram?
Beleza, então o meu programa está funcionando, foi sucesso.
Se o livro o resultado real foi que o livro
continua ainda por exemplo, disponível, então ocorreu erro.
O que é que eu tenho que fazer?
Debugar o meu programa e escrever código que faça ele funcionar, ser bem sucedido.
Então esse é o caso de teste,
quando eu empresto livro ao usuário que os 2 são válidos.
O ct2, não é, que é o caso de teste 2,
eu empresto livro ao usuário com nenhum livro emprestado,
ou seja ele não tinha emprestado nenhum livro da biblioteca antes.
Ou seja, o tamanho da lista de livros dele antes era 0.
Ao emprestar esse livro, a lista dele passa a ser 1,
então o meu caso teste aí é simplesmente,
verificar que dado que livro e usuário válidos que o usuário
ele não tinha nenhum livro emprestado, então, a lista de livros dele vai ser,
esperada, é 1, o resultado real tem que ser 1 também.
Se não bater, vai dar erro e eu vou precisar debugar o meu código
correspondente ou de produção correspondente a esse teste.
Eu vou exemplificar aqui o código, vamos voltar lá para vocês verem, o ct1, não é,
é o empresta o livro ao usuário então percebam que esse caso teste,
quando vocês vêm isso no fluxo no ciclo do
TDD está lá sim: "Escreva o teste" "Escreva o teste
de modo que ele falhe", então agora nós vamos escrever o teste.
Ele vai falhar porque nós não vamos ter provavelmente nós não, ele vai
falha porque nós não vamos ter o código de produção que vai fazer ele funcionar.
Então, vejam esse caso teste, de teste,
como é que eu transformo ele num teste realmente quando você faz,
encontra lá no ciclo do TDD, escreva o teste, está certo?
Ora vejam como é que fica.
Nós começamos, eu estou usando aqui o padrão AAA,
que é estruturar o meu caso teste
usando o arrange, o act e o assert.
O assert é o caso teste que eu estou querendo provar,
ele é o caso teste que eu estou querendo provar.
Então eu começo sempre pelo assert porque o meu caso teste está lá.
Eu estou querendo mostrar nesse caso do ct1,
que ao emprestar livro para alguém, esse livro se torna indisponível.
Então, o que eu escrevi ali no meu assert é isso,
eu estou testando se isso ocorreu mesmo,
porque no nosso SAB, na biblioteca,
quando eu eu faço o empréstimo de livro,
o livro fica guardando para qual usuário que foi, ocorreu o empréstimo.
Então eu coloco lá, se o usuário é o 1 e eu estou usando o livro 2,
ao obter qualquer usuário do livro 2, tem que bater,
tem que ser true, porque eu estou pondo assertEquals, está certo?
Aí eu vou construir agora a parte do act.
Eu parto sempre do assert, agora vou construir a parte do act.
Bom, eu quero que isso seja verdadeiro.
Para ser verdadeiro, eu tenho que fazer o quê?
Emprestar o livro 2 para o usuário 1.
Veja como é simples de fazer, eu vou fazendo isso.
Bom aí tem, essa é a parte do act, agora tem a parte do arrange.
A parte do arrange, é tudo o que eu preciso
fazer para criar objetos e outras coisas mais,
para que eu possa fazer o meu act e o meu assert.
No caso aqui, está tudo feito no setup mesmo e o que é eu criei no setup?
Usuário 1 e livro 2.
Só isso que eu fiz, que eu precisei aqui, logo lógico no meu setup lá,
eu eu criei mais outras coisas para o meu exemplo ficar mais real,
mas aqui eu só preciso disso e isso ficou lá.
Às vezes o arrange fica com alguma coisa lá no setup e
alguma coisa aqui no meu teste que eu escrevi por JUnit.
Outro caso teste para a responsabilidade empresta livro.
que eu estou considerando o caminho feliz ainda porque o livro e o usuário são
válidos.
É o ct3, o caso de teste 3,
eu empresto 3 livros ao usuário com nenhum livro emprestado.
Porquê 3?
Não, podia ser 2, podia ser 5.
Eu estou emprestando vez, quando eu emprestei 1 livro e ele não
tinha nenhum livro emprestado, ele passou a ter 1 livro.
Agora, eu quero ver se emprestando 2,
emprestando 3 ele vai ter esse total de livros que eu estou emprestando.
Então, o tamanho da lista de livros de usuários após esse empréstimo de 3
livros para esse usuário, tem que ser 3.
Então, eu tenho caso teste que está bem simples aí, que é livro, usuário,
espero que a lista de livros do usuário seja 3
e o real, quando eu rodar o meu programa,
a lista, quando o empréstimo for realizado, tem que ser 3.
Está certo?
Agora o ct4, então nós vamos lá para o caminho alternativo, o teste negativo.
Agora a gente vai olhar que o livro pode ser válido ou
inválido e o usuário pode ser válido ou inválido ou os 2 podem ser inválidos.
Então vamos começar pelo caso teste ct4.
Eu empresto livro válido, já emprestado ao usuário válido,
ou seja, o livro, ele já foi emprestado para alguém.
Significa que ele está indisponível para novo empréstimo para outro usuário,
aquele dado livro.
Está certo?
Então meu caso teste, se vocês olharem aí,
está escrito lá, a entrada: livro já emprestado e usuário.
Se o livro está emprestado, eu espero que seja lançada uma exceção,
aí eu estou colocando a exceção com nome,
pode ser o nome mais apropriado para alguém que esteja escrevendo,
eu achei a exceção livro indisponível para empréstimo, está certo?
isso é o que eu espero.
E quando eu rodar o programa,
tem que sair uma exceção do tipo livro indisponível para empréstimo.
Vai bater com o que eu espero, se não bater,
significa que no meu código está alguma coisa errada.
Novamente, esse ct4 que eu vou mostrar daqui a pouco, como é que eu construo,
como é que eu escrevo o código de teste ou o teste, está certo?
Como é que eu escrevo esse código de teste?
Vai ser a partir desse caso teste,
esse que está entre colchetes é caso teste, caso de teste, está certo?
O ct5 eu empresto livro inválido ao usuário válido.
Então eu estou lá, o que é que é livro inválido?
É livro null.
Está certo?
Então o usuário é válido, aí eu vou lançar uma exceção e aí você pode dar o nome
mais apropriado que você queira, está certo?
Então poderia ser exceção do livro inválido, por exemplo, né, está certo?
Agora o ct4 aqui, eu vou mostrar, eu vou voltar para vocês darem uma olhadinha,
que eu estou trabalhando código apropriado, escrevendo código apropriado.
Onde é que a gente começa a escrever?
Através do Assert, né, então o que é isso?
Empresta o livro válido já emprestado ao usuário válido.
O que é que vai acontecer no meu caso teste?
Vai voltar uma exceção.
Como é que a gente faz isso no JUnit?
A gente coloca lá cima no expected,
qual é a exceção que eu estou esperando está certo?
E a exceção que eu estou esperando é livro indisponível para empréstimo,
essa é a exceção que eu estou esperando aí nesse caso.
Então, o assert ele é implícito, eu não preciso por nada.
Quando é exceção ela aparece lá cima.
Se por acaso, o meu código falhar, o meu código não for
apropriado, se ele lançar a exceção certa,
esse código que eu pus aí ele vai capturar e vai voltar verde.
Se ele lançar se perder e lançar alguma coisa que não seja
a exceção que eu estou esperando, vai aparecer barra vermelha, está certo?
Vai aparecer barra vermelha.
Bom, com base nisso, eu trabalho no Act.
O que é que eu quero fazer?
Eu quero emprestar o livro.
O que que eu estou emprestando o livro?
Eu estou emprestando livro que já foi emprestado para outro usuário,
então eu simplesmente ponho empréstimo do livro.
Bom, se eu quero que ele seja já emprestado,
já na parte do arrange o que é que eu tenho que fazer?
É emprestar ele de novo, tá certo, ou seja ele vai ser emprestado primeiro,
novamente ali.
Por isso que eu estou repetindo biblioteca empresta livro 2 ao usuário 1,
porque eu tinha colocado emprestar o livro 2 para o usuário 3, no caso do Act.
Então, o que eu estou fazendo?
Eu estou emprestando livro já emprestado, ele já foi emprestado,
o 2 para o usuário 1.
Agora eu estou emprestando para o usuário 3 de novo?
Não está certo isso, vai ter que aparecer alguma exceção.
Então, é assim que a gente constrói.
Nesse caso é exemplo que parte do Arrange está no set up.
Então o que é que está lá no set up?
É o livro usuário 1, usuário 3 e livro 2.
Já está lá no set up.
E apenas aqui no código de teste, eu coloquei biblioteca empresta livro,
livro 2 usuário 1 está fazendo parte com
uma fixture no meu código de teste.
Aí continuando com o negative testing, a gente tem o ct6,
que eu empresto livro válido a usuário inválido.
Está certo?
Então no meu caso teste eu vou colocar lá livro, livro qualquer válido,
o usuário eu coloco, ele é inválido, então eu coloco null, está certo?
Eu coloco null e aí ele vai me voltar uma exceção, porque o usuário é inválido.
Aí seria por exemplo, tipo de exceção que eu espero, que seria usuário inválido,
por exemplo.
E eu espero também que quando o código for rodado real,
o código de produção, ele vai corresponder à essa exceção,
se não corresponder ele tem que ser debugado até que faça isso funcionar.
Já na ct7 eu empresto livro inválido a usuário inválido.
Então os 2 são inválidos.
Então os 2, livro é null, usuário é null,
volta uma exceção que essa exceção poderia ser por exemplo,
livro inválido e usuário inválido, por exemplo.
O nosso objetivo aqui então era exemplificar a definição
de casos testes, uma coisa mais concreta que vocês já tinham uma noção,
que era no caso cima do SAB, o sistema de automação de bibliotecas.
E nós mostramos então para vocês que através da responsabilidade empresta
livro, nós conseguimos definir alguns casos de testes e eu exemplifiquei
também como é que eu escreveria caso de teste do caminho feliz e
caso de teste do negative testing ou caminho alternativo,
como é que eu escreveria isso no JUnit, está certo?
Obrigado.
[MÚSICA]
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.
