Mule esb teste parte 1

1. 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

2. 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:

3. • 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
}
}

4. 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.

5. • 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

6. • 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="
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"};
}
}

7. 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

8. 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.