[ad_1]
Os testes de unidade são executados em diferentes estágios durante o ciclo de vida do desenvolvimento. Conforme mencionado na primeira postagem no blog desta série, MUnit para programadores Java: Introdução, os testes de unidade desempenham um papel essencial nos estágios de implementação, manutenção e evolução do ciclo de vida de um projeto. Os testes podem ser executados durante cada uma dessas etapas e os resultados são coletados e analisados. Se o aplicativo passar na série de testes, continuará em sua jornada pelo ciclo de vida do projeto. No entanto, para que a execução seja possível, é necessário um chicote de teste. Nesta postagem do blog, examinarei as maneiras pelas quais o JUnit e o MUnit executam testes e fornecem resultados.
Contents
Execução de teste
A execução do teste MUnit depende do tempo de execução do Mule. O tempo de execução do Mule deve estar em execução com êxito antes que os testes do MUnit possam ser executados. Isso leva tempo e adiciona um atraso para a execução do teste. Por outro lado, o JUnit possui um equipamento de teste leve e os testes são executados quase imediatamente. É importante considerar ao projetar processos que requerem execução de teste. Normalmente, os testes são executados como parte de um pipeline de CI / CD e durante o desenvolvimento. Para testes MUnit, pode ser conveniente executar um subconjunto desses testes. Isso permite que apenas sejam executados os testes relevantes para o desenvolvimento realizado.
Executando um subconjunto de testes JUnit
O JUnit fornece uma abordagem orientada a anotações e interface de marcador para definir subconjuntos de casos de teste. O teste é anotado com o @Categoria anotação que é configurada com uma interface de marcador que representa o nome da tag pela qual classificar o caso de teste.
|
@Teste @Categoria(Afirmação.classe) público vazio testAssertEquals() { Corda real = “animais”; assertEquals(“Todos os animais são iguais, alguns mais que outros”, real, “animais”); } interface Afirmação {} |
FIg 1: O caso de teste é anotado com a interface do marcador.
Uma classe vazia é anotada com as classes de caso de teste que contêm anotações para a interface de marcador especificada.
|
@Correr com(Categorias.classe) @IncludeCategory(Afirmação.classe) @SuiteClasses({AssertionTest.classe, OnlyCatTest.classe}) público classe AssertionTestSuite {} |
Fig 2: Os conjuntos de teste e categoria são configurados em uma classe de conjunto de testes.
Executando um subconjunto de testes MUnit
A identificação de casos de teste é muito mais simples no MUnit. Qualquer teste pode ser marcado com uma ou mais tags. Isso é feito no munit: test elemento.
|
<munit:teste nome=“afirmar-igual” Tag=“afirmação”> |
Fig 3: Caso de teste marcado com “asserção”.
Para executar um subconjunto de casos, os testes do MUnit podem ser executados usando o Maven Plugin. Todos os testes marcados ou um subconjunto de testes marcados podem ser executados na linha de comando.
|
mvn limpar limpo teste –Dmunit.Tag=afirmação,zombar |
Fig 4: Executado apenas os casos de teste anotados com asserção e simulação.
Como alternativa, o arquivo POM pode ser configurado para executar um conjunto de casos de teste marcados.
|
<plugar> <groupId>com.mulesoft.munit.Ferramentas</groupId> <artifactId>munit–maven–plugar</artifactId> <versão>2.2.1</versão> <configuração> <munitTags>afirmação</munitTags> </configuração> </plugar> |
Fig 5: Configure o plug-in MUnit Maven para executar apenas asserções de tags de teste.
Além de especificar a tag, você pode especificar o arquivo XML de configuração de teste MUnit real a ser executado quando o teste for iniciado.
|
mvn limpar limpo teste –Dmunit.teste=afirmação–teste–suíte.xml mvn limpar limpo teste –Dmunit.teste=.*suíte.xml (regular expressão) mvn limpar limpo teste –Dmunit.teste=afirmação–teste–suíte.xml# assert-equals <munitTest>afirmação–teste–suíte.xml# assert-equals |
Fig 6: As várias maneiras de executar o subconjunto de testes.
Ignorar o recurso nos testes JUnit
JUnit permite que os testes sejam ignorados anotando casos de teste com o @Ignorar anotação.
|
@Teste @Ignorar público vazio testAssertThatHasItems() { assertThat(Matrizes.asList(“gato”, “cachorro”, “hamster”), hasItems(“gato”, “hamster”)); } |
Fig 7: Ignore este teste quando os testes são executados.
Ignorar recurso nos testes MUnit
MUnit permite que os testes sejam ignorados, definindo o ignorar atributo do munit: test elemento para true.
|
<munit:teste nome=“afirmar-igual” Tag=“afirmação” ignorar=“verdade”> |
Fig 7: Defina o atributo ignore como true.
Todos os testes podem ser ignorados, definindo o -DskipTests sinalizador em uma execução do Maven ou no skipMunitTests elemento no arquivo POM.
|
mvn limpar limpo pacote –DskipTests <skipMunitTests>verdade</skipMunitTests> |
Fig 8: Configure o Maven para executar testes.
Suspensão e tempo limite com JUnit
O comportamento relacionado ao tempo pode ser simulado no JUnit adormecendo um encadeamento. Existem várias maneiras de fazer isso, mas uma maneira é usar o método sleep () da classe java.util.concurrent.TimeUnit. Os tempos limites podem ser testados para usar a regra org.junit.rules.Timeout ou definir a propriedade timeout do @Teste anotação.
|
@Regra público Tempo esgotado globalTimeout = Tempo esgotado.milis(1000); @Teste público vazio testSleep() joga InterruptedException { TimeUnit.MILLISECONDS.dormir(5000); } @Teste(tempo esgotado = 500) público vazio testTimeOut() joga InterruptedException { TimeUnit.MILLISECONDS.dormir(5000); } |
Fig 9: O tempo limite e o sono definidos no caso de teste.
Suspensão e tempo limite com MUnit
A MUnit replicou a funcionalidade de suspensão configurando o processador de eventos de suspensão com um tempo para aguardar valor e unidade de tempo.
|
<munit–Ferramentas:dormir Tempo=“1” doc:nome=“Dormir” timeUnit=“MINUTOS”/> |
Fig 10: Configure o processo do evento de suspensão para aguardar.
O tempo limite está configurado no munit: test elemento com o tempo esgotado atributo. Por padrão, os testes do MUnit atingem o tempo limite após dois minutos.
|
<munit:teste nome=“timeout-test-suiteTest” tempo esgotado=“5000”> |
Fig 11: Defina o atributo timeOut no elemento munit: test.
Maven e MUnit
Como já vimos, os testes MUnit são executáveis através do comando Maven teste limpo do mvn, graças ao plug-in MUnit Maven. Este plug-in também configura o relatório de cobertura de teste, permitindo configurar a porcentagem de cobertura de teste e o formato do relatório.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
<plugar> <groupId>com.mulesoft.munit.Ferramentas</groupId> <artifactId>munit–maven–plugar</artifactId> <versão>2.2.1</versão> <execuções> <execução> <Eu iria>teste</Eu iria> <Estágio>teste</Estágio> <metas> <objetivo>teste</objetivo> <objetivo>cobertura–relatório</objetivo> </metas> </execução> </execuções> <configuração> <cobertura> <runCoverage>verdade</runCoverage> <formatos> <formato>html</formato> <formato>console</formato> </formatos> <requiredApplicationCoverage>80</requiredApplicationCoverage> <requiredResourceCoverage>10</requiredResourceCoverage> <requiredFlowCoverage>80</requiredFlowCoverage> </cobertura> </configuração> </plugar> |
Fig 12: O MUnit Maven Plugin fornece uma variedade de opções de configuração.
A localização padrão do relatório de cobertura de teste é {raiz do projeto} target site munit cobertura recursos.
Resultados do teste e MUnit
Os relatórios do Surefire podem ser configurados para gerar quando os testes do MUnit são executados via Maven, mvn surefire-report: relatório. Por padrão, os relatórios do Surefire estão localizados no diretório {raiz do projeto} target surefire-reports diretório e o relatório HTML está localizado em {raiz do projeto} target site.
|
<plugar> <artifactId>maven–infalível–plugar</artifactId> <versão>2.20.1</versão> <configuração> <grupos>com.mulesoft.afirmação.AssertionTestSuite</grupos> </configuração> </plugar> |
Fig 13: Configure o plug-in Maven Surefire para gerar relatórios de teste.
Conclusão
Esta série de postagens no blog explorou a estrutura de teste do MUnit da perspectiva de um programador Java, mostrando que há semelhanças impressionantes entre a maneira como um desenvolvedor Java implementaria testes e como um desenvolvedor Mule atenderia ao mesmo requisito. Em muitos casos, a abordagem replica exatamente a abordagem JUnit, como no teste de asserção. Em outros casos, o MUnit cria sua própria visão sobre como os testes devem ser aplicados, como a implementação do Spies.
Qualquer desenvolvedor Java experiente não terá problemas para se adaptar à implementação de teste de unidade usando o MUnit.
Se você estiver interessado em aprender mais sobre o MUnit e as atividades relacionadas ao DevOps essenciais para implementar aplicativos Mule prontos para produção, considere nosso curso Anypoint Platform Development: Production-Ready Development Practices (Mule 4).
[ad_2]
