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: Projeto Antecipado (BDUF) Versus Nenhum Projeto (NoDUF)
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
312 ratings
Na lição
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!
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá.
Bem-vindo ao curso TDD- Desenvolvimento de Software Guiado por Testes.
Eu sou Clovis Fernandes.
Hoje, nós vamos falar de conjunto de siglas que aparece aí.
Bom. Vou aproveitar para dizer que eu demorei
para aprender a diferença entre sigla e acrônimo.
Então, vocês vejam que aí eu tenho, por exemplo, ITA.
ITA, é acrônimo para Instituto Tecnológico de Aeronáutica.
Já, por exemplo, a palavra IBM é uma sigla para International Business Machine.
O que diferencia, então, sigla de acrônimo?
O acrônimo, eu posso ler como se fosse uma palavra.
ITA é acrônimo.
IBM, como eu soletro cada letra é uma sigla.
Nós temos aí, a sigla TDD.
Então, TDD é uma sigla porque eu leio letra por letra.
Então TDD é o Text Driven Development ou Designer,
que corresponde a desenvolvimento, português, não é?
Desenvolvimento de Software Guiado por Testes.
Ao final dessa aula, você saberá que não é preciso fazer
projecto antecipado e completo do curso para você fazer o TDD.
Então, essas siglas que estão aí se referem mais ou menos a isso.
Então, quando eu falo o BDUF vou misturar com acrônimo.
Vou ler como se fosse sigla e acrônimo, BDUF Big Design Up Front,
que é o projecto grande antecipadamente.
Então, eu estou querendo dizer para vocês que eu,
para fazer TDD eu não preciso fazer isso antes de implementar e também não
vou fazer a outra sigla que é o NoDUF.
No, D, U, F.
Eu não vou usar essa que é Nenhum, Design algum antecipadamente.
No Design Up Front.
Nem, não vou fazer nada disso também.
Então, na aula de hoje o que eu quero ver é eu preciso fazer
projecto antecipado e completo antes para fazer o TDD?
Vamos tentar responder e mostrar que não e nem o seu oposto
que é não fazer nada que muitas pessoas da comunidade do TDD,
acham que isso é certo, nós discordamos pouco.
Então, o que é que vem a ser o BDUF?
Big Design Up Front.
Projeto Grande feito antecipadamente.
Está certo?
Nós vamos tentar mostrar que no TDD, isso não vai ser necessário.
O BDUF corresponde, então, a projecto da sua aplicação que
seria feito e completado e aperfeiçoado antes da implementação começar.
Isso, normalmente, é feito outros projetos.
O processo cascata exemplifica bem o BDUF.
Uau! aqui!
linda cascata que estamos vendo aí!
Mas não é dessa cascata que eu estou falando,
mas o nome foi derivado por causa disso.
O que eu estou falando é desse processo de desenvolvimento de software,
que eu tenho lá cima os requisitos, uma análise de requisitos,
o projeto, a implementação, a verificação e testes,
o software é colocado produção e entra manutenção.
O BDUF, esse Big Design Up Front,
ele corresponde à análise de requisitos e ao design,
exatamente antes da implementação.
Se o BDUF não é uma boa alternativa para o TDD, porque eu não quero,
nesse processo de cascata, eu perco muito tempo fazendo
a especificação de coisas que podem ser ou inúteis ou que vão mudar no futuro.
Eu levo muito tempo fazendo isso.
Depois, faço o projeto de tudo e aí começo a implementar e só depois vou testar.
TDD a gente não faz isso, né, o nosso processo é testar antes,
fazer falhar,
fazer o código funcionar, refatorar.
É esse ciclo que nós vamos seguir.
Então, se o BDUF não é uma boa alternativa,
qual é que é a alternativa boa para isso?
Obviamente, na comunidade TDD,
existem muitos que praticam e acham que o oposto disso do BDUF,
que é fazer tudo antes da implementação, o oposto,
que é não fazer muita coisa antes da implementação, está certo?
Seria o ideal.
Eu vou mostrar aqui,
com alguns exemplos não computacionais que isso talvez não seja uma coisa boa.
Eu vou estar chamando isso de NoDUF, No Design Up Front,
português, design algum antecipadamente,
ou seja, não vou fazer nenhum design, está certo?
Antecipadamente.
Será que essa é uma boa alternativa?
Bom, quero lembrar que essa sigla NoDUF,
não é usualmente empregada na literatura ou na indústria de software.
Eu estou usando aqui é, exatamente,
só para pontuar a conceituação sobre o que estou querendo dizer, que é,
não fazer quase nenhum projeto antecipado.
Então, eu estou chamando de NoDUF, No Design Up Front.
Projeto Algum Antecipadamente.
Eu não vou fazer nada antecipadamente ou muito pouco.
Está certo?
Isso é o que a comunidade TDD, muitos pensam e fazem uso disso.
Eu discordo e vou mostrar alguns exemplos,
não computacionais que vão exemplificar isso.
Suponha que, na imagem a seguir, eu queira fazer uma corrida campestre de motos e
aí eu tenho duas perguntas que eu gostaria de fazer para,
você olha a imagem, está certo?
E vai responder: seria bom local?
Eu tenho informações suficientes para começar essa corrida?
Está certo?
Então, esse é trechinho de uma imagem, eu estou mostrando onde eu vejo,
que tem grana, que tem uma trilha no meio.
Está certo?
Então, olhando isso o que é que você pode imaginar?
Aparentemente sim, eu posso fazer uma corrida de motos aí, mas,
veja eu não tenho informações suficientes, eu tenho poucas informações,
eu estou olhando de uma maneira muito restrita esse meu local, está certo?
Agora, vamos ampliar esse local.
Uau!
Uma bela vista também.
Mas, as duas perguntas, não é?
Será que é bom local?
E tenho informações suficientes?
Agora, eu tenho mais informações e certamente, esse não é bom
local para fazer uma corrida de motos, uma corrida campestre de motos,
porque o lugar é muito perigoso, está à beira de precipícios.
Então, bastou eu ampliar pouquinho, olhar pouquinho à frente,
ter pouquinho mais de informação, eu já pude tomar uma decisão.
O NoDUF corresponde a você estar olhando
de maneira limitada e não ver à frente alguma coisa.
Então, não é uma boa coisa.
A gente viu que não é uma boa coisa ter, querer fazer,
ter todas as informações antes, não é?
No Big Design Up Front.
Mas, também no NoDUF, não ter nenhuma informação,
ou ter muito pouca informação, também não é uma coisa boa.
Imagina agora que eu queira fazer uma pesquisa de campo sobre biodiversidade.
num determinado local.
Vamos responder novamente às mesmas perguntas.
Seria bom local?
Eu tenho informações suficientes para começar?
Então, esse é o trecho do que eu quero fazer.
Está certo?
Fazer essa análise de campo, essa exploração de campo,
de biodiversidade, está certo?
Olhando para isso, aparentemente sim, seria bom local, tenho muita vegetação,
certamente eu vou ter muitos animais e outras informações ali.
Só que também eu não tenho muitas informações suficientes.
No caso agora, vou olhar, ampliar,
eu estou olhando de uma maneira muito limitada, não é?
Está certo?
Agora, vamos ampliar isso pouquinho?
Pronto.
Uau! Uma bela cena também.
Está certo?
Vocês vejam que agora, eu tenho mais informações.
Está certo?
Eu tenho mais informações agora.
Quer dizer, bastou olhar pouquinho além e eu já consigo
vislumbrar outras necessidades para essa minha pesquisa aí, está certo?
Eu tenho montanhas, eu tenho vale extenso.
Então, talvez eu precise que algum dos biólogos
façam escaladas, façam rappel.
e gostaria de saber também algumas outras informações adicionais,
como chuva, clima da região etcetera e tal.
A resposta nesse caso, certamente sim, porque ao olhar pouquinho
mais eu consigo vislumbrar mais sobre
a pesquisa de campo e a resposta é certamente sim, é bom local para isso.
E eu agora tenho a informação suficiente para uma tomada de decisão,
preliminar, pelo menos.
Está certo?
Então, a chave aqui é isso: conjunto de
informações suficiente, quer dizer, agora eu tenho mais informações.
Ou seja, eu não preciso ter todas as informações,
por exemplo, dessa última pesquisa de campo,
informações topográficas e coisas adicionais sobre isso,
eu não preciso ter conjunto de informações completas.
Mas eu preciso ter conjunto de informações suficientes,
para eu poder iniciar a minha pesquisa de campo.
Então, a chave não é ter muita informação antes de começar
a implementar e nem quase nenhuma informação antes de começar a implementar.
É ter o conjunto de informações suficiente.
Como nós vamos chegar a definir o que é informação suficiente,
isso vai ser outra coisa.
Nessa nossa aula, eu espero que você tenha então entendido
que o desenvolvimento de
software usando a abordagem BDUF, ou seja, Big Design Up Front,
não é uma coisa boa, nem o seu oposto, quase nenhuma informação.
No BDUF, você demora a começar
a implementar e o seu sistema já vai ficar muito rígido,
porque eu tomo muitas decisões antecipadamente e se precisar mudar alguma
coisa, eu vou ter dificuldade, exatamente por causa dessa rigidez.
No caso do NoDuf ou seja, eu não tenho design nenhum, né, está certo?
Nem de requisitos, nem do design propriamente dito, está certo?
O que é que acontece?
Às vezes, eu não tenho todos os requisitos, eu não tenho informações,
eu não consegui olhar para a frente sobre alguns percalços que eu
possa ter no meu desenvolvimento.
E ao fazer isso,
talvez eu tenha problemas no futuro, porque eu posso seguir, o projeto
vai sendo seguido para desenvolvimento que pode me levar a problemas.
Está certo?
Ele talvez não esteja muito pronto também para mudanças inesperadas.
Eu vou contar caso aqui para vocês, pessoal, hoje ele é grande cientista,
começou a fazer uma tese de mestrado comigo, torno de 2003, 2004,
que era sobre repositório inteligente para gerenciar o perl programming,
né, na modelagem ágil, que ele começou a programar esse repositório
inteligente usando o TDD, TDD individual, né, está certo?
Chegou dado momento, e ele estava usando essa técnica,
que eu vou colocando os meus requisitos, e eu imagino que vai
emergir uma arquitetura, projeto do meu sistema que seja saudável.
Quando ele veio me apresentar esse projeto, o projeto tinha muitas falhas,
ele não conseguia me responder muitas coisas,
ele não era muito inteligente, o que é que faltou?
Faltou ele ter uma visão pouquinho mais antecipada disso,
ele teria que ter olhado a literatura sobre outros repositórios
inteligentes para fazer análises parecidas,
e ao não ter olhado isso, ele fez uma arquitetura que acabou sendo
inadequada para suportar os novos requisitos.
Ou seja, mesmo você querendo não,
não seguindo plenamente o TDD,
olhando o suficiente para a frente, você pode ter problemas.
A conclusão a que nós devemos chegar, é que o certo é fazer projeto
suficiente antecipadamente, nem muito, nem pouco.
O suficiente, e fazer o suficiente não é uma coisa também que a gente tem
certeza do que vai ser feito.
Nós sempre vamos ficar dúvida, mas esse é o assunto da próxima aula.
Espero então que tenha ficado claro que você não vai
precisar fazer projeto usando o BDUF ou NoDuf.
Obrigado!
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
