{"id":1572,"date":"2023-05-04T13:58:05","date_gmt":"2023-05-04T16:58:05","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1572"},"modified":"2023-08-04T13:20:15","modified_gmt":"2023-08-04T16:20:15","slug":"o-que-sao-testes-unitarios","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/o-que-sao-testes-unitarios\/","title":{"rendered":"O que s\u00e3o Testes Unit\u00e1rios?"},"content":{"rendered":"\n

Fala pessoal beleza!<\/p>\n\n\n\n

O nosso objetivo nesse post \u00e9 entender o que \u00e9 um teste unit\u00e1rio? Os testes unit\u00e1rios s\u00e3o pequenos m\u00e9todos independentes que implementamos para testar alguma parte do nosso c\u00f3digo. Digamos que n\u00f3s temos um m\u00e9todo na nossa classe que precise ser testado para garantir que ele funcione conforme o esperado. Pra garantir isso precisaremos implementar um ou mais testes unit\u00e1rios. Cada teste unit\u00e1rio \u00e9 um m\u00e9todo muito pequeno que criamos. \u00c9 um pequeno peda\u00e7o de c\u00f3digo que implementamos para invocar o m\u00e9todo que est\u00e1 sendo testado.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Considerando a imagem acima, estou testando um m\u00e9todo chamado generateCoupon<\/strong>. Ent\u00e3o, o m\u00e9todo JUnit que criarei invocar\u00e1 o m\u00e9todo generateCoupon<\/strong> e validar\u00e1 se produziu um resultado esperado. Para testar o c\u00f3digo da aplica\u00e7\u00e3o, geralmente implementamos mais de um teste unit\u00e1rio. Um teste unit\u00e1rio testar\u00e1 o nosso m\u00e9todo com par\u00e2metros v\u00e1lidos, enquanto outros testes unit\u00e1rios passar\u00e3o intencionalmente par\u00e2metros inv\u00e1lidos ao nosso m\u00e9todo. E em ambos os cen\u00e1rios, os testes unit\u00e1rios validar\u00e3o se o m\u00e9todo que estivermos testando produz o resultado esperado.<\/p>\n\n\n\n

O c\u00f3digo dos testes unit\u00e1rios \u00e9 muito simples e geralmente \u00e9 muito curto, e \u00e9 por isso que no lado direito imagem, ilustrei cada teste unit\u00e1rio com um elemento muito menor que o elemento que representa o m\u00e9todo que est\u00e1 sendo testado no lado esquerdo. O m\u00e9todo do lado esquerdo pode conter uma l\u00f3gica de neg\u00f3cios muito complexa. E \u00e9 por isso que eu optei por representa-lo com um elemento muito grande.<\/p>\n\n\n\n

Simplificando, um teste unit\u00e1rio tamb\u00e9m \u00e9 um c\u00f3digo que voc\u00ea escreve, mas \u00e9 muito pequeno e \u00e9 um c\u00f3digo muito simples que n\u00e3o cont\u00e9m muita l\u00f3gica de neg\u00f3cios. \u00c9 um c\u00f3digo muito simples porque tudo o que ele faz \u00e9 chamar um m\u00e9todo e test\u00e1-lo usando par\u00e2metros espec\u00edficos e validar o resultado retornado.<\/p>\n\n\n\n

\u00c9 muito importante ter em mente que os testes unit\u00e1rios devem testar apenas uma funcionalidade espec\u00edfica. N\u00e3o devemos tentar criar um \u00fanico teste unit\u00e1rio que teste v\u00e1rios m\u00e9todos da nossa classe ao mesmo tempo. Para implementar nossos testes unit\u00e1rios, usaremos o JUnit 5. O JUnit nos fornece uma API para implementar pequenos trechos de c\u00f3digo para testar nossos m\u00e9todos.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Conforme a imagem acima a nossa aplica\u00e7\u00e3o pode conter muitas classes e cada classe pode conter v\u00e1rios testes unit\u00e1rios para garantir que uma boa cobertura de testes e por consequ\u00eancia garantir o comportamento esperado. O ideal \u00e9 implementarmos mais de um teste unit\u00e1rio para a maioria dos m\u00e9todos da nossa classe.<\/p>\n\n\n\n

Independente da IDE, pelo menos nas que eu j\u00e1 trabalhei, quando a execu\u00e7\u00e3o do teste unit\u00e1rio for bem-sucedida ele ser\u00e1 marcado com a cor verde. Mas quando o resultado n\u00e3o corresponde ao esperado ocorre uma falha e ele ser\u00e1 marcado com uma cor vermelha. \u00c9 por isso que nessa imagem temos alguns testes unit\u00e1rios coloridos em verde e alguns testes unit\u00e1rios que falharam coloridos em vermelho.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Avaliando mais de perto um \u00fanico teste unit\u00e1rio. Inicialmente vamos come\u00e7ar com um exemplo de c\u00f3digo muito simples e \u00e0 medida que nos sentirmos mais \u00e0 vontade com os testes unit\u00e1rios, veremos exemplos mais complexos. Vamos supor que temos uma classe chamada SimpleMath<\/em>, e ela possui um m\u00e9todo muito simples chamado sum<\/em> que recebe dois par\u00e2metros do tipo Double<\/em>. Ele possui regras de neg\u00f3cio muito simples e tudo o que ele faz \u00e9 realizar a soma dos dois par\u00e2metros e retornar o resultado tamb\u00e9m do tipo Double<\/em>. Mas mesmo sendo um exemplo de c\u00f3digo muito simples, esse m\u00e9todo ainda deve ser testado. Por exemplo, e se um desenvolvedor cometeu um erro de digita\u00e7\u00e3o e, em vez da soma, realizou uma multiplica\u00e7\u00e3o ou subtra\u00e7\u00e3o? Pra prevenir isso podemos e devemos implementar testes unit\u00e1rios para garantir que esse c\u00f3digo funcione corretamente. Para testar esse m\u00e9todo, podemos implementar um teste unit\u00e1rio que se pare\u00e7a com o trecho de c\u00f3digo da imagem abaixo.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Nos pr\u00f3ximos posts falarei de forma mais aprofundada sobre a estrutura dos testes unit\u00e1rios e todos os seus detalhes. Ent\u00e3o, n\u00e3o se preocupe se por enquanto as coisas se parecerem um pouco estranhas ou confusas, pouco a pouco tudo far\u00e1 sentido. Por exemplo, voc\u00ea deve ter notado que o nome do m\u00e9todo parece muito incomum. \u00c9 muito longo e tem anota\u00e7\u00e3o @Test. Mas n\u00e3o se preocupe, falaremos sobre isso nos pr\u00f3ximos posts.<\/p>\n\n\n\n

Observe, que este m\u00e9todo \u00e9 dividido em tr\u00eas se\u00e7\u00f5es principais. A primeira delas \u00e9 chamada de Given ou Arrange. \u00c9 nesta se\u00e7\u00e3o, que criamos uma nova inst\u00e2ncia da classe SimpleMath<\/em>. A segunda se\u00e7\u00e3o \u00e9 chamada de when ou act e \u00e9 nesta se\u00e7\u00e3o que invocamos o m\u00e9todo a ser testado sum passando a ele dois par\u00e2metros v\u00e1lidos. O m\u00e9todo sum que como voc\u00ea deve imaginar soma os dois Doubles \u00e9 o m\u00e9todo que estou testando. E ele \u00e9 chamado de method under Test ou em uma tradu\u00e7\u00e3o direta m\u00e9todo em teste.<\/p>\n\n\n\n

Claro queremos ter certeza de que esse m\u00e9todo funciona conforme o esperado e realiza a soma corretamente. Ent\u00e3o eu passo dois par\u00e2metros e armazeno o valor retornado em uma nova vari\u00e1vel chamada actual<\/em>. Por fim temos a terceira se\u00e7\u00e3o que \u00e9 chamada de then ou assert, e esta \u00e9 uma se\u00e7\u00e3o onde eu uso m\u00e9todos do JUnit para verificar se o resultado est\u00e1 correto. 6.2 somado com 2 deve produzir 8.2 como resultado. Ent\u00e3o eu uso um m\u00e9todo especial do JUnit chamado assertEquals para verificar se o resultado armazenado na vari\u00e1vel actual<\/em> est\u00e1 correto. O primeiro par\u00e2metro que o assertEquals aceita \u00e9 o valor esperado. E nesse caso esperamos que o resultado seja igual 8.2. O segundo par\u00e2metro \u00e9 um valor real que foi retornado do m\u00e9todo de soma e o terceiro par\u00e2metro \u00e9 uma mensagem de erro opcional que ser\u00e1 impressa no console se esse teste unit\u00e1rio falhar. Ent\u00e3o, se 6.2 somado com 2 n\u00e3o produzir 8.2, significa que esse teste unit\u00e1rio ir\u00e1 falhar e a mensagem “6.2 + 2 did not produce 8.2!” ser\u00e1 impressa no console. Como eu j\u00e1 disse, n\u00e3o se preocupe se voc\u00ea estiver se sentindo um pouco confuso e perdido neste momento. Nos pr\u00f3ximos posts, iremos implementar testes unit\u00e1rios na pr\u00e1tica, execut\u00e1-lo e vermos como tudo funciona.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Conforme imagem acima se executarmos os testes unit\u00e1rios no meu ambiente de desenvolvimento, como por exemplo, na Spring Tool Suite ou no Eclipse e este teste unit\u00e1rio passar teremos uma barra verde. Mas se meu m\u00e9todo de soma n\u00e3o retornar o resultado esperado e meu teste unit\u00e1rio falhar, veremos uma barra vermelha e claro haver\u00e3o mais informa\u00e7\u00f5es sobre a falha impressas no console e tamb\u00e9m no painel de resultados do teste. Claro, diferentes ambientes de desenvolvimento ter\u00e3o diferentes interfaces de usu\u00e1rio para os relat\u00f3rios de teste, mas em ess\u00eancia os testes unit\u00e1rios bem-sucedidos sempre ser\u00e3o verdes e os testes unit\u00e1rios com falha sempre ser\u00e3o vermelhos.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Resumindo testes automatizados s\u00e3o um processo em que os desenvolvedores implementam e executam testes muito simples que testam partes individuais da aplica\u00e7\u00e3o. Os testes unit\u00e1rios s\u00e3o muito pequenos e s\u00e3o executados muito rapidamente. Eles rodam muito r\u00e1pido porque, ao testar um m\u00e9todo, quaisquer depend\u00eancias que esse m\u00e9todo possa ter s\u00e3o substitu\u00eddas por objetos mockados. Considerando a imagem acima, se por exemplo o m\u00e9todo que estou testando faz uma requisi\u00e7\u00e3o HTTP e depende do objeto HTTPClient, um objeto HTTPClient real precisar\u00e1 ser substitu\u00eddo por uma vers\u00e3o fake ou mockada dele. E pode haver diferentes tipos desses objetos fakes. Pode haver um objeto fake, pode haver um objeto mockado ou pode ser um objeto spy. E claro falaremos mais sobre esses diferentes tipos de objetos fakes em posts futuros.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ent\u00e3o, conforme no diagrama acima o objeto do HTTPClient real ser\u00e1 substitu\u00eddo pela vers\u00e3o mockada dele e nenhuma requisi\u00e7\u00e3o HTTP real ser\u00e1 enviada e isso far\u00e1 com que nosso teste unit\u00e1rio seja executado muito mais r\u00e1pidamente. N\u00f3s fazemos isso porque precisamos que o teste unit\u00e1rio n\u00e3o esteja realmente testando como um HTTPClient funciona. O teste que precisamos \u00e9 focado apenas em testar o c\u00f3digo dentro do m\u00e9todo que estamos testando. Se o m\u00e9todo que estivermos testando depende de outro objeto, a depend\u00eancia precisar\u00e1 ser substitu\u00edda por um objeto mockado. Quando todas as depend\u00eancias externas forem substitu\u00eddas por objetos mockados, com comportamento predefinido ou com valores codificados, o m\u00e9todo que estamos testando funcionar\u00e1 muito r\u00e1pido e nossos testes unit\u00e1rios tamb\u00e9m funcionar\u00e3o muito r\u00e1pido. E \u00e9 por isso que, se necess\u00e1rio, podemos e devemos implementar mais de um teste unit\u00e1rio para testar um \u00fanico m\u00e9todo. Por exemplo, um teste unit\u00e1rio ir\u00e1 testar o m\u00e9todo passando par\u00e2metros v\u00e1lidos. Outros testes unit\u00e1rios ser\u00e3o para testar o m\u00e9todo com par\u00e2metro inv\u00e1lidos, e outros testes unit\u00e1rios podem ser para testar o m\u00e9todo com resposta inv\u00e1lida do HTTPClient. Enfim podemos implementar diferentes testes unit\u00e1rios para garantir que o m\u00e9todo que estamos testando funcione corretamente e seja confi\u00e1vel em diferentes condi\u00e7\u00f5es e sempre produza o resultado esperado.<\/p>\n\n\n\n

Bom creio que com esse breve in\u00edcio j\u00e1 deu pra ter ideia do qu\u00e3o importante \u00e9 testar nosso c\u00f3digo. Por esse post \u00e9 isso e no pr\u00f3ximo eu vou abordar diversos outros motivos para implementarmos testes unit\u00e1rios. Ent\u00e3o fiquem ligados pra n\u00e3o perderem nada!<\/p>\n\n\n\n \n

Treinamentos relacionados com este post<\/h2>\n\n\n\n\n<\/a>\n\n\n\n\n\n<\/a>\n\n\n\n\n<\/a>\n\n\n\n\n<\/a>\n\n\n\n\n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n","protected":false},"excerpt":{"rendered":"

Fala pessoal beleza! O nosso objetivo nesse post \u00e9 entender o que \u00e9 um teste unit\u00e1rio? Os testes unit\u00e1rios s\u00e3o pequenos m\u00e9todos independentes que implementamos para testar alguma parte do nosso c\u00f3digo. Digamos que n\u00f3s temos um m\u00e9todo na nossa classe que precise ser testado para garantir que ele funcione conforme o esperado. Pra garantir […]<\/p>\n","protected":false},"author":1,"featured_media":1584,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[279,280,118,278],"tags":[281,284,283,282],"_links":{"self":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1572"}],"collection":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1572"}],"version-history":[{"count":8,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1572\/revisions"}],"predecessor-version":[{"id":1623,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1572\/revisions\/1623"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1584"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}