{"id":1592,"date":"2023-05-16T08:29:00","date_gmt":"2023-05-16T11:29:00","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1592"},"modified":"2023-08-04T13:21:12","modified_gmt":"2023-08-04T16:21:12","slug":"o-principio-f-i-r-s-t","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/o-principio-f-i-r-s-t\/","title":{"rendered":"O Princ\u00edpio F.I.R.S.T."},"content":{"rendered":"\n<p>Fala pessoal beleza! Ao implementar testes unit\u00e1rios, os bons desenvolvedores tentam, tanto quanto poss\u00edvel, seguir o princ\u00edpio FIRST. Na real, FIRST \u00e9 uma combina\u00e7\u00e3o de v\u00e1rios princ\u00edpios, e neste post aprenderemos sobre esses princ\u00edpios. A primeira letra do princ\u00edpio FIRST significa FAST ou em portugu\u00eas r\u00e1pido. Os testes unit\u00e1rios s\u00e3o pequenos peda\u00e7os de c\u00f3digo que executam uma tarefa espec\u00edfica. Como os testes unit\u00e1rios s\u00e3o pequenos e, ao contr\u00e1rio dos testes de integra\u00e7\u00e3o, n\u00e3o se comunicam com servidores ou bancos de dados remotos, eles s\u00e3o executados muito rapidamente.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/www.erudio.com.br\/blog\/wp-content\/uploads\/2023\/05\/Screenshot-2023-05-03-10.25.21.png\" alt=\"\" class=\"wp-image-1593\" width=\"409\" height=\"324\" srcset=\"https:\/\/www.erudio.com.br\/blog\/wp-content\/uploads\/2023\/05\/Screenshot-2023-05-03-10.25.21.png 621w, https:\/\/www.erudio.com.br\/blog\/wp-content\/uploads\/2023\/05\/Screenshot-2023-05-03-10.25.21-300x238.png 300w\" sizes=\"(max-width: 409px) 100vw, 409px\" \/><\/figure>\n\n\n\n<p>A pr\u00f3xima letra no princ\u00edpio FIRST significa INDEPENDENT o que claro em portugu\u00eas \u00e9 independente. Idealmente, os testes unit\u00e1rios devem ser independentes uns dos outros. Um teste unit\u00e1rio n\u00e3o deve depender do resultado produzido por outros testes unit\u00e1rios. Na verdade, por padr\u00e3o, os testes unit\u00e1rios s\u00e3o executados em uma ordem aleat\u00f3ria. Isso n\u00e3o \u00e9 \u00f3bvio e n\u00e3o sabemos realmente qual teste unit\u00e1rio ser\u00e1 executado primeiro e qual teste unit\u00e1rio ser\u00e1 executado em segundo lugar. O c\u00f3digo que estivermos testando ou o <em>system under test<\/em> tamb\u00e9m deve ser isolado de suas depend\u00eancias. E isso \u00e9 para garantir que o bug em uma depend\u00eancia n\u00e3o influencie um teste unit\u00e1rio. Portanto, as depend\u00eancias geralmente s\u00e3o mockadas ou usamos stubs com dados predefinidos. E desta forma os testes unit\u00e1rios podem testar o <em>system under test<\/em> de forma isolada de suas depend\u00eancias e produzir um resultado muito preciso.<\/p>\n\n\n\n<p>A pr\u00f3xima letra no princ\u00edpio FIRST significa REPEATABLE ou em portugu\u00eas repet\u00edvel. N\u00f3s precisamos que o processo seja repet\u00edvel. E se executarmos os mesmos testes unit\u00e1rios v\u00e1rias vezes, eles devem produzir o mesmo resultado. Se precisarmos que o teste seja executado em um computador diferente, ele tamb\u00e9m deve produzir o mesmo resultado. \u00c9 por isso que precisamos de testes independentes do ambiente e de outros testes unit\u00e1rios. Os par\u00e2metros que o m\u00e9todo e o teste requerem s\u00e3o geralmente predefinidos e codificados, e se o m\u00e9todo que estivermos testando precisar ser testado com par\u00e2metros v\u00e1lidos e inv\u00e1lidos, voc\u00ea criar\u00e1 dois, tr\u00eas ou mais testes unit\u00e1rios diferentes. Cada teste unit\u00e1rio testar\u00e1 o m\u00e9todo com seu pr\u00f3prio conjunto de par\u00e2metros predefinidos. E desta forma precisamos que o teste se torne repet\u00edvel. E se o executarmos v\u00e1rias vezes em ambientes diferentes em um computador diferente ou em um sistema operacional diferente, ele ainda produzir\u00e1 o mesmo resultado toda vez que o executarmos.<\/p>\n\n\n\n<p>A pr\u00f3xima letra significa <em>self-validating <\/em>ou autovalida\u00e7\u00e3o. E isso significa que, para saber se o teste passou ou n\u00e3o o desenvolvedor n\u00e3o deve fazer nenhuma verifica\u00e7\u00e3o manual adicional. Ap\u00f3s a conclus\u00e3o do teste ele mesmo precisar\u00e1 auto validar o resultado. O <em>method under test<\/em> por si mesmo decidir\u00e1 se o teste unit\u00e1rio est\u00e1 passando ou falhando. Depois que o teste unit\u00e1rio for conclu\u00eddo, o resultado dever\u00e1 ficar claro.<\/p>\n\n\n\n<p>Por fim a \u00faltima letra representa <strong><em>Thorough &amp; Timely<\/em><\/strong> que em portugu\u00eas significa dizer que, ao testar um m\u00e9todo, devemos considerar tanto o caminho feliz quanto o cen\u00e1rio negativo. E isso significa que, na maioria das vezes, criamos v\u00e1rios testes unit\u00e1rios para testar um m\u00e9todo que aceita diversos tipos de par\u00e2metros. Um teste unit\u00e1rio testar\u00e1 seu m\u00e9todo com par\u00e2metros v\u00e1lidos e outros testes unit\u00e1rios testar\u00e3o o m\u00e9todo com par\u00e2metros inv\u00e1lidos. E se houver um intervalo como valor m\u00ednimo e m\u00e1ximo, devemos criar testes unit\u00e1rios adicionais para testar valores m\u00ednimos e m\u00e1ximos tamb\u00e9m.<\/p>\n\n\n\n<p>Al\u00e9m disso \u00e9 melhor criar os testes unit\u00e1rios no momento em que estivermos trabalhando na funcionalidade. Dessa forma, temos mais confian\u00e7a de que as regras de neg\u00f3cios funcionam conforme o esperado e h\u00e1 menos chances de introduzirmos um bug e ele acabar entrando em produ\u00e7\u00e3o. Portanto, antes de disponibilizarmos nosso c\u00f3digo em produ\u00e7\u00e3o, ele deve ser coberto por testes unit\u00e1rios. Bom pessoal por esse post \u00e9 isso no pr\u00f3ximo post falaremos sobre como testar c\u00f3digo em isolamento!<\/p>\n\n\n\n&nbsp;\n<h2>Treinamentos relacionados com este post<\/h2>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_tests_java\" target=\"_blank\" rel=\"noopener\">\n\n<img decoding=\"async\" style=\"max-width: 100%;\" title=\"Java Unit Testing com Spring Boot 3, TDD, Junit 5 e Mockito\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/24-tests_java.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_ci_cd_java_aws\" target=\"_blank\" rel=\"noopener\">\n\n<img decoding=\"async\" style=\"max-width: 100%;\" title=\"Java Continuous Integration e Continuous Delivery com AWS e Github Actions\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/27_CICD_JavaAWS.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_ci_cd_java_azure\" target=\"_blank\" rel=\"noopener\">\n\n<img decoding=\"async\" style=\"max-width: 100%;\" title=\"Java Continuous Integration e Continuous Delivery com Microsoft Azure e Github Actions\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/28_CICD_JavaAzure.png\">\n<\/a>\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_rest_spring_java\" target=\"_blank\" rel=\"noopener\">\n\n<img decoding=\"async\" style=\"max-width: 100%;\" title=\"REST API's RESTFul do 0 \u00e0  AWS com Spring Boot 3, Java e Docker\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/07-rest-spring-java.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_rest_asp_net\" target=\"_blank\" rel=\"noopener\">\n\n<img decoding=\"async\" style=\"max-width: 100%;\" title=\"REST API's RESTFul do 0 \u00e0 Azure com ASP.NET Core 5 e Docker\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/01-rest-asp.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_rest_spring_kotlin\" target=\"_blank\" rel=\"noopener\">\n        <img decoding=\"async\" style=\"max-width: 100%;\" title=\"REST API's RESTFul do 0 \u00e0 AWS com Spring Boot 3, Kotlin e Docker\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/18-rest-spring-kotlin.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_microservices_java\" target=\"_blank\" rel=\"noopener\">\n        <img decoding=\"async\" style=\"max-width: 100%;\" title=\"Microservices do 0 com Spring Cloud, Spring Boot e Docker\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/14-microservices-java.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_microservices-dotnet\" target=\"_blank\" rel=\"noopener\">\n        <img decoding=\"async\" style=\"max-width: 100%;\" title=\"Arquitetura de Microsservi\u00e7os do 0 com ASP.NET, .NET 6 e C#\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/15-microservices-dotnet.png\">\n<\/a>\n\n<a href=\"https:\/\/pub.erudio.com.br\/kr\/blog_ms_kotlin\" target=\"_blank\" rel=\"noopener\">\n        <img decoding=\"async\" style=\"max-width: 100%;\" title=\"Microsservi\u00e7os do 0 com Spring Cloud, Kotlin e Docker\" src=\"https:\/\/raw.githubusercontent.com\/leandrocgsi\/blog-images\/main\/22-ms-kotlin.png\">\n<\/a>\n","protected":false},"excerpt":{"rendered":"<p>Fala pessoal beleza! Ao implementar testes unit\u00e1rios, os bons desenvolvedores tentam, tanto quanto poss\u00edvel, seguir o princ\u00edpio FIRST. Na real, FIRST \u00e9 uma combina\u00e7\u00e3o de v\u00e1rios princ\u00edpios, e neste post aprenderemos sobre esses princ\u00edpios. A primeira letra do princ\u00edpio FIRST significa FAST ou em portugu\u00eas r\u00e1pido. Os testes unit\u00e1rios s\u00e3o pequenos peda\u00e7os de c\u00f3digo que [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1594,"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\/1592"}],"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=1592"}],"version-history":[{"count":4,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1592\/revisions"}],"predecessor-version":[{"id":1625,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1592\/revisions\/1625"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1594"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}