Mule ESB Teste: Teste unitario e

funcional – Parte 1

Abstrato

ensaios, tal como geralmente reconhecido é uma

parte importante do processo de desenvolvimento de

software. Os testes devem ser aplicadas durante

cada fase do processo de desenvolvimento de

software de testes de desenvolvedor para testes de

aceitação. Em engenharia de software ternos de

teste abrangentes e automatizadas irá garantir a

qualidade do software e pode fornecer uma rede de

segurança para alterações de regressão e de

incompatibilidade.

Em projetos de integração ESB Mule essas mesmas

questões surgem. Componentes usados nos fluxos

de mula, os próprios fluxos e a integração de fluxos

em um contexto de sistema precisa ser testado.

Este artigo é o primeiro de uma série de artigos

sobre ensaio de projectos Mule ESB em todos os

níveis. Ele está se concentrando em componentes

menores em um projeto de mula que são testados

com a unidade e testes funcionais.

Teste de Software - A pirâmide de teste

Antes de mergulhar no assunto, vamos dar uma

olhada no contexto de testes. Idealmente testes de

projetos de software é construído de baixo para

cima. Começando com uma grande base de caso de

teste de testes de unidade automatizados para os

menores componentes que compõem o aplicativo

inteiro juntos. Subindo através de camadas de

arquitetura o número de casos de teste diminui para

componentes maiores, porque eles são

composições dos componentes já testados.

Atingindo finalmente o topo da pirâmide em que a

supervisão manual ou testes manuais formam o topo

da pirâmide testar a aplicação como um todo [1].

Source: http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-

cream-cone/

Automated testing pyramid

testes unitários

No mais baixo nível testes unitários verificar a

funcionalidade correta de classes. Essas classes

podem ser em um projeto de mula simples

extensões e personalizações do quadro Mule.

Exemplos incluem:

• Transformadores personalizadas

• Os componentes personalizados

• avaliadores expressão personalizada

• E, em geral, todos os beans Spring que um pedido

de mula vai usar. Tipicamente, em um projeto de

multi módulo estes feijões são parte de uma

dependência e, portanto, são testados

separadamente na dependência construída.

Os testes de unidade em um sentido clássico pode

testar a funcionalidade de classes personalizadas

sem disparar até Mule. Uma classe POJO simples e

é caso de teste que contém lógica de transformação

cliente poderia ter esta aparência:

public class CustomerTransformationComponent {

public Map<String, Object> tranformCustomer(Customer customer) {

Map<String, Object> returnMap = Maps.newHashMap();

returnMap.put("name", customer.getName());

// Fields mapping

// ...

return returnMap;

}

}

public class CustomerTranformationComponentTest {

@Test

public testTransform() {

Customer testCustomer = new Customer();

// Create test data

Map<String, Object> customerMap = new CustomerTransformationCompone

nt()

.tranformCustomer(testCustomer);

// Assert test data

}

}

Quando a funcionalidade de classes personalizadas requer um contexto

de mula do Quadro Mule fornece um Kit de Teste de Compatibilidade

(TCK) para as extensões de teste e personalizações [3]. Para cada tipo

de componente Mule há uma classe pai abstrato que é derivado de

org.mule.tck.junit4.AbstractMuleTestCase. Eles estão localizados em

mule-core-3.5.2-tests.jar para Mule version 3.5.2.

Por exemplo, um componente Java que implementa a interface Mule

mobilizável com uma lógica complexa confiando no Contexto Mule pode

ser testada com as classes de teste acima mencionados:

public class CustomerComponent implements Callable {

@Autowired

public CustomerService service;

@Overwrite

public Object onCall(MuleEventContext eventContext) throws Exception {

String customerId = (String) eventContext.getMessage().getPayload()

;

Customer customer = service.getCustomer(customerId);

Map<String, Object> customerDetails = transformCustomer(customer);

return customerDetails;

}

}

public class CustomerComponentTest extends SimpleJavaComponentTestCase {

@Test

public testOnCall() {

// Create test data

MuleEvent event = getTestEvent(payload, muleContext);

new CustomerComponent().onCall(new DefaultMuleEventContext(event));

// Assert test data

}

}

Estes testes unitários são benéficos para as seguintes razões:

• componentes testados com um caso de teste TCK assegurar que o

comportamento comum do componente é compatível com o quadro de

mula.

• Usando um caso de teste TCK permite que o desenvolvedor se

concentrar em escrever testes para o comportamento específico do seu

componente.

• Onde teste de um método na API de componentes não pode ser

testada pelo caso de teste TCK, os casos de teste fornece um método

abstrato para o teste, garantindo os testes de desenvolvedor todas as

áreas do componente.

• O TCK fornece um modelo de teste padrão que é um simples conjunto

de classes de teste. O desenvolvedor não precisa se preocupar em

escrever novas classes de teste para os seus casos de teste a cada vez.

Por exemplo. o ciclo de vida de mula de um componente é

automaticamente testada.

Teste Funcional Mule

Quando se trata de testar a interação de componentes entre si em sub

fluxos ou "simples" flui testes funcionais são a maneira recomendada de

teste [4]. Porque Mule ESB é leve e facilmente incorporáveis na testa o

uso de classe theorg.mule.tck.junit4.FunctionalTestCase do TCK é

recomendado para testar peças ou fluxos inteiros. Isto é feito através da

criação de uma unidade de teste, que é derivada a partir desta classe

que vai proporcionar uma instância mula nivelado com um contexto da

mula para efectuar testes funcionais destes fluxos mula.

A ênfase de tais testes é os seguintes aspectos de tais fluxos:

• funcionalidade da mensagem corre-se

• manipulação de Validação e roteamento baseado em regras dentro

destes fluxos

• E a sua manipulação de erro

Por exemplo, uma sub fluxo que é suposto ser chamado poderia ser

assim:

<sub-flow name="subFlow" doc:name="subFlow">

<component class="de.codecentric.example.CustomerComponent" doc:name="Ja

va"/>

</sub-flow>

Para ser capaz de chamar essa sub fluxo de embrulhar a chamada com

um ponto final VM e guardá-lo em um arquivo de teste de recursos XML:

<flow name="TestFlow" doc:name="TestFlow">

<vm:inbound-endpoint exchange-pattern="request-response" path="TestFlow" doc:name="VM endp

oint"/>

<flow-ref name="subFlow" doc:name="Call sub flow for testing"/>

</flow>

Os testes unitários correspondentes ficaria assim:

public class SubFlowTest extends FunctionalTestCase {

@Test

public void testFlow() throws Exception{

MuleClient client = muleContext.getClient();

String inputPayload = "550e8400-e29b-11d4-a716-446655440000";

// Create test data

MuleMessage reply = client.send("vm://TestFlow", inputPayload, null

, 5000);

assertNotNull(reply);

assertNotNull(reply.getPayload());

// Assert test data

}

@Override

protected String[] getConfigFiles() {

return new String[]{"./src/test/app/sub-flow-test.xml",

"./src/main/app/sub-flow.xml"};

}

}

Substituindo o protected String[] getConfigFiles() método fornece o

caso de teste os arquivos de configuração de configuração e da mola

mula necessários. Recomendamos para dividir a descrição xml produção

e fornecer a configuração XML de teste em um arquivo XML separat que

só é usado em testes específicos.

Este é um exemplo simples como o fluxo pode ser testada sem

zombando ou alterar os testes internamente. Mule fornece uma maneira

de adicionar <test:component/> componentes em um fluxo para os testes

que fornece zombeteiros e funcionalidade de teste. Nós não preferem

deste modo porque a descrição fluxo será misturado com informações de

teste. Recomendamos o uso de tais casos, a biblioteca MUNIT que é

descrito no artigo seguinte blogue.

Testando o (sub) fluxos usando uma mula incorporado e com uma clara

separação entre o teste e descrição do fluxo de produção oferece os

seguintes benefícios:

• Configurações e fluxos pode ser testado isoladamente um do outro o

que proporcionará uma separação mais limpa de testes e reduzir o

tamanho de cada caso de ensaio. Os erros podem ser identificados deste

modo mais focada, porque eles podem ser localizados em casos de teste

explícitos.

• Não se pretende testar novamente componentes padrão da mula,

porque pode ser assumido que eles já são testados exaustivamente.

Portanto, somente certos caminhos e componentes de fluxos criados

pelos desenvolvedores são necessários para o teste.

• Os casos de teste precisa fornecer uma infra-estrutura de teste própria

que é feita de preferência de nos componentes de infra-estrutura de

memória por exemplo VM como um transporte, ActiveMQ para JMS ou

H2 como um banco de dados. Isso é necessário porque o ambiente de

produção pode não ser sempre fornecida automatizada ou incorporado

para um teste de unidade devido a licença, recurso ou motivos de

desempenho.

• Reutilizar entre os testes, por exemplo, da infra-estrutura em memória

pode ser aumentada fornecendo a configuração apenas uma vez para

todos os casos de teste.

Conclusão

Nós demos neste artigo do blog uma introdução para os primeiros

passos no teste de aplicativos da mula. A partir descrevendo como no

menor componentes da camada de arquitectura e (sub) flui de uma

aplicação da mula pode ser testado e que beneficiam ele produz. Nós

descrito para o efeito testes de unidade clássicos com JUnit no âmbito

contexto TCK mula e os testes funcionais para a TCK. Estes testes

podem ser encontrados em aplicações módulo mula individuais ou em

bibliotecas que contêm componentes e sub-fluxos que são utilizados em

aplicações multi módulo mula.