Engenharia de Software - Desenvolvimento dirigido por testes

E aí [Música] o Olá eu sou professor Marcelo Fantinato Essa é a disciplina engenharia de software e nós vamos falar agora do desenvolvimento dirigido por testes bom o que é o desenvolvimento dirigido por testes é é uma abordagem dentro da engenharia de software em que nós seguimos um processo um pouco diferente da abordagem tradicional o que eu chamo de abordagem tradicional e abordagem em que a primeiro eu faço a implementação a quantificação e depois eu vou fazer o teste Isso é o que a gente vê normalmente nos processos dos métodos tradicionais requisitos projeto implementação e

teste e a abordagem de desenvolvimento dirigido por testes ela inverte e isso né por isso que ela é chamada como aparece aqui embaixo de também chamada de teste Force detesta primeiro ou seja você coloca o teste antes da implementação inverte primeiro você dessa para depois implementar Mas como é isso como é que você vai testar algo que ainda não existe calma que daqui um pouco vocês vão entender isso melhor mas a ideia justamente Essa é você testar antes mesmo de ter o que testar é bom o nome oficial é test-driven development do inglês né por

isso a sigla tdd e em português a gente usa a sigla td2 não sabendo que é da cidade do nome em inglês é bastante comum a gente usar falar que a gente Segue o tdd se pega a abordagem tdd para o desenvolvimento com essa abordagem nela nasceu no contexto dos métodos ágeis Mais especificamente nos XP no Extreme Extreme programming me como uma das dos princípios uma da dos princípios que era um seguir que são seguidos nessa abordagem mas dada a sua popularidade ela se Estendeu por outros métodos hoje ela é amplamente usada inclusive em métodos

tradicionais da engenharia de software ou seja e métodos que não são as mesmo equipes que empresas equipes que não seguem os métodos ágeis ainda sim seguem ao várias delas seguem a o teste ou desenvolvimento orientado dirigido por teste o DVD ou o teste Force 1 bom então essa abordagem ela na verdade ela é uma abordagem aquela intercalated e desenvolvimento até se desenvolve teste desenvolve teste desenvolve de certa forma o teste de unidade ele já é isso né só que desenvolve teto desenvolve teste desenvolve testa agora é testa e desenvolve peça desenvolvem inverteu e continue e

vai intercalando esse FS intercalação ela é feita necessariamente por meio de implementos de software então vocês devem se lembrar aqui os métodos ágeis trabalham muito com incremento embora outros métodos tradicionais também trabalhem com incrementos e o próximo incremento né você faz o incremento você só vai fazer um próximo incremento um outro pedacinho do Foster apenas depois que o anterior tiver passado em todos os testes não significa que apenas depois que ele tiver sido testado se ele tiver sido testado e espalhado em pelo menos 1 o teste você tem que corrigir e aí depois que ele

passar em todos os testes OK vamos para o próximo incremento vamos a evoluir agora ir para o próximo é incremento significa seguir esse processo aqui esse processo significa primeiro identifica uma funcionalidade e é primeiro eu identifico uma funcionalidade que vai ser implementada uma vez que identifiquei uma funcionalidade para ser implementada a primeira coisa é escrever um teste para ela é projetar um caso de teste certo projetar um caso de teste e é esse caso de teste ele ele vai ser escrito antes mesmo da funcionalidade ser implementada então se eu tenho lá vão pegar aquele exemplo

é simplesinho ilustrativo de um cálculo de raiz quadrada Então em vez antes mesmo de implementar uma função um método que calcula a raiz quadrada eu vou fazer um teste escrever um teste para testar aquela função que ainda nem existe a se eu entrar com quatro tem que sair dois se eu entrar com menos um tem que sair resultado inválido alguma coisa assim eu faço alguns testes não só mas eu faço alguns testes seguindo aquelas ideias lá de quantos testes mínimos eu preciso para conseguir testar várias situações equivalentes bom uma vez que eu escrevi o teste

então eu executo esse teste olha e o que vai acontecer quando eu executar esse teste a primeira vez e vai falhar porque porque a função ela nem foi implementada bom E aí eu pergunto aqui passou ou falhou se tivesse passado eu viria viria para cá mas na primeira vez é claro que falhou se Falhou Eu venho implementar a funcionalidade eu errei faturar bom na primeira vez não faz sentido refatura porque eu tô implementando pela primeira vez aí eu venho novamente executar esse teste que já tá implementado Olha que bom né então não existe aquele risco

de implementei bom não dá atender o testar porque eu tenho que implementar logo o próximo nesse caso já está implementado eu executo E aí passou ou falhou na melhor das hipóteses na segunda vez que o executar o teste que é a primeira vez que eu tô executando depois que foi implementado né na melhor das hipóteses passa e aí boa fecha aquele ciclo e vou para o próximo mas se falhar pelo menos um caso de teste falhar eu tenho que vir aqui e corrigir refatorar o corrigir o defeito e eu fico nesse círculo aqui até que

todos aqueles testes que eu tenho que o que eu tiver implementado para aquela funcionalidade que eu estou desenvolvendo tem Tá certo então por isso é a ideia de testar primeiro eu testo antes mesmo de implementar na verdade é quase que uma que o que é uma alegoria né porque é claro que vai falhar Então nem preciso testar mas o que eu tenho é que escrever o teste antes para depois implementar isso é seguido o desenvolvimento dirigido por testes certo essa nova funcionalidade ela deve ser pequena implementável com poucas linhas de código Claro que não precisa

ser simplesmente calcular uma raiz quadrada não precisa ser alguma coisa tão simples assim mas é o ideal é que seja algo pequeno várias eu vou fazer implementos Vinhos e Implementos Vinhos e Implementos vinhos de forma bem controlada certo esse teste A ideia é que ele seja automatizado feto quando eu escrevo esse teste na verdade eu estou automatizando um teste porque eu tô falando inclusive de testes de unidade né E como eu já havia dito a primeira vez que eu executo teste ele vai falhar é na verdade eu sempre estou executando todos os testes que eu

já tenho em cima de todos os incrementos que eu já desenvolvi então todos os testes que eu já tinha vão passar em cima da aplicação que eu já tenho que em teoria está funcionando porque eu não mexi a hora que eu fizer a nova implemente daí só vai falhar os novos casos de teste o que eu criei porque a implementação nova ainda não foi feita Quando eu fizer a nova implementação e eu resetar o teste aí o que pode acontecer os novos casos de teste que eu criei para Nova funcionalidade podem passar ou não tomara

que todos passem mas e os antigos que estavam passando pode ser que eles falem por quê porque pode ser que ao criar uma nova funcionalidade eu preciso de mexer uma coisa que já existia E aí pode ser que eu estrague essa coisa e aí aqueles casos de teste que já estavam automatizados eles apontem o defeito Olha que ótimo porque porque essa abordagem faz com que o vá criando um conjunto de testes automatizados cada vez maior que eu sempre vou executando e de vez em quando algum que tava passando para começa a falhar porque porque eu

mexi em algo que eu não deveria ter mexido certo esse conjunto de teste que vai aumentando aumentando aumentando e eu sempre vou executando e ele sempre vai passando mas em algum momento ele Pode falhar esse conjunto de teste é chamada de testes de regressão por quê Porque eu sempre rodo um teste de regressão quando eu estou implementando algo novo o teste de regressão é para saber se o que já estava funcionando não regrediu por isso que a gente chama de teste de regressão Ah é então algumas características né Eu preciso de um ambiente de teste

automatizado não dá para ficar fazendo isso manualmente por exemplo de yunit é e Unity né de unidade porque esse tipo de TSE para teste de unidade Oi e o Jade Java né para quem tava vários vocês já devem ter ouvido falar ou até mesmo usado Talvez o dinheiro na net é focado no teste de unidade ajuda os programadores a esclarecerem suas dúvidas sobre o que o código deve fazer então para fazer o teste antes o programador tem que entender bem o código ou a funcionalidade que ele vai implementar isso ajuda na hora da implementação do

código propriamente dito e depois ainda vai ter que pensar no teste de sistema no teste de integração e no teste do sistema no teste de aceitação validação é porque porque isso aqui sai só cobre o teste de unidade certo como benefícios eu é por tabela eu acabo tendo uma boa cobertura do código eu faço o teste de regressão com menor custo que eu havia mencionado ali agora pouco a depuração é a simplificada porque uma vez que eu fico a falha ele já vai estar associado necessariamente a um pedaço de código porque é feito um teste

para um pedaço de código um teste para um pedaço de código um teste um pedaço de código quando um teste falha mesmo teste de regressão eu já sei bom ok então teste falhou tal caso de teste falhou e ele está associado a qual parte do código eu vou direto naquela parte do código eu não preciso ficar usando aquelas ferramentas de depuração ficar depurando para achar onde está o defeito é muito mais fácil e esses casos de teste acabam servindo de documentação do sistema porque eles acabam ajudando a explicar como que o sistema funciona bom gente

isso então é uma visão Geral do que a gente chama de desenvolvimento dirigido por testes por quê Porque eu me uso os testes para orientar todo o desenvolvimento em vez dos Testes seria um quadro e eles acabam sendo um ator principal no ciclo de desenvolvimento de testes de softwares como referência é o livro de engenharia de software do Summer viu a décima edição de 2018 é isso obrigado a [Música] [Música]