Mule esb teste parte 3

Mule ESB Teste: Testando Sistema End-to-End com

Docker

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

podem fornecer uma rede de segurança para a regressão e as mudanças

incompatíveis.

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 último em uma série de artigos sobre projetos de teste Mule

ESB em todos os níveis (parte 1, parte 2). Ele está se concentrando no teste

end-to-end sistema global de um projeto de mula que é realizado através da

criação de infra-estrutura com a ESB e um servidor de simulação usando

Docker.

A infraestrutura

Para executar um teste do sistema end-to-end para uma aplicação Mule

precisamos de pelo menos três componentes do sistema diferentes:

• App: Primeiro de tudo, necessita da aplicação de mula em teste.

• Tester: A parte de teste realiza testes do aplicativo em teste. Este tipo de

teste pode ser realizada por testes simples que realizam chamadas de API e

verificar os resultados ou complexos orquestrada chamadas com uma

ferramenta de teste, como JMeter.

https://blog.codecentric.de/en/2015/06/mule-esb-testing-part-33-system-end-to-end-testing-with-docker/

https://blog.codecentric.de/en/2015/06/mule-esb-testing-part-33-system-end-to-end-testing-with-docker/

• Mock: Então precisamos de um ou de sistema múltiplo simulações, que

representam os sistemas de aplicação é dependente. Mountebank pode

fornecer essa funcionalidade.

Tal configuração do sistema end-to-end ficaria assim:

Docker

Docker é uma tecnologia de código aberto que permite a virtualização de

máquinas como contentores isolados no sistema host. Ele fornece a criação

rápida e eficiente e recursos de contentores em um host usando tecnologias

Linux, como cgroups e namespaces. Isso permite a criação de infra-

estruturas portáteis, reprodutíveis e imutáveis. Estes são um grande bônus

para a criação, a execução reprodutível de cenários de teste que incluem

infra-estrutura.

Para uma melhor integração de um teste de tal sistema end-to-end em um

gasoduto da integração contínua do uso de tecnologia de conteinerização é

uma vantagem. Uso de Docker por exemplo, permitirá que o rápido

arranque e paragem de uma instância Mule isolado com o aplicativo e um

servidor de simulação.

Aplicativo em teste

https://blog.codecentric.de/files/2015/06/system-ed-to-end.png

Vamos supor, por exemplo, o seguinte cenário simples. Uma aplicação

Mule fornece uma API REST na porta 8080, que internamente chama outro

serviço backend RESTO na porta 9000. Esse pedido

pode parecer que:

Vemos neste exemplo um ponto de extremidade HTTP que escuta na porta

8080 e rotas de todas as solicitações para um roteador de API REST. O

pedido para o / myResource vai para o sub fluxo fundo e irá desencadear

uma chamada de HTTP de saída para um servidor na porta 9000. O

resultado é transformado em uma string e retornado ao chamador depois.

Em caso de exceções, uma estratégia exceção retornará o resultado

approriate.

Assumimos temos um conjunto de nossa aplicação mula já como uma

única aplicação em um recipiente de encaixe, conforme descrito neste post.

servidor Mock

https://blog.codecentric.de/files/2015/06/Bildschirmfoto-2015-06-09-um-22.24.31.png

Para permitir a aplicação Mule para realizar chamadas para os serviços de

back-end potenciais em um cenário de ponta a ponta do sistema, uma

tecnologia como charlatão pode ser usado.

Charlatão é uma ferramenta de código aberto, que fornece multi-

plataforma, teste multi-protocolo funciona em uma rede. Uma aplicação

que é suposto ser testado, só precisa apontar para o IP ou URL de uma

instância de charlatão em vez da dependência real. Permite testar a sua

aplicação por toda a pilha de aplicativos, como você faria com tocos e

zomba tradicionais. Os protocolos suportados incluem HTTP, HTTPS, TCP

e SMTP.

Para o nosso cenário, o impostor mountebank seria definido como seguida,

retornando uma resposta ridicularizado na porta 9000:

{

"port": 9000,

"protocol": "http",

"name": "My Mock",

"mode": "text",

"stubs": [

{

"responses": [

{

"is":

{

"statusCode": 200,

"headers": {

"Content-Type": "application/json"

},

"body": "{ \"message\": \"You got mocked data\" }"

}

}

],

"predicates": [

{

"equals": {

"path": "/anotherResource"

}

}

]

}

]

}

Assumimos criámos o nosso servidor simulada em um recipiente de

encaixe, bem como, conforme descrito neste post.

Definição de teste

Agora, para definir o nosso teste, usamos um teste de integração JUnit

simples usando a biblioteca com garantia de descanso integrado em uma

compilação Maven. Está chamando a API REST e verificar que o resultado

é os dados zombaram do servidor simulada. Nesse ponto, as chamadas para

o servidor simulada através do charlatão API REST pode ser realizada para

fins de verificação também.

Tal teste ficaria assim:

public class SystemIT {

@Test

public void testMyResource() {

RestAssured.baseURI = System.getProperty("system.url");

RestAssured.defaultParser = Parser.JSON;

// Verify an system end-to-end call

given()

.param("mimeType", "application/json")

.get("/api/myResource")

.then().assertThat()

.header("content-type", containsString("application/json"))

.body("message", equalTo("You got mocked data"));

}

}

Configuração de teste

A automação desse cenário é executada usando Maven e a janela de

encaixe-maven-plugin. Para esse efeito, definimos duas imagens Docker,

um para o aplicativo de mula e um para o servidor de simulações:

<plugin> <groupId>org.jolokia</groupId>

<artifactId>docker-maven-plugin</artifactId>

<version>0.11.5</version>

<configuration> <dockerHost>${boot2docker.url}</dockerHost>

<images> 

<image> <name>mule-app</name>

<alias>mule-app</alias>

<run>

<ports> <port>${webservice.port}:${webservice.port}</port>

</ports>

<links> <link>rest-mock:backend</link>

</links>

<wait>



<log>Server startup</log>

<url>${boot2docker.address}:${webservice.port}/api/console</url>

<time>8000</time>

<shutdown>500</shutdown>

</wait>

<log> <prefix>Mule</prefix>

<date>ISO8601</date>

<color>blue</color>

</log>

</run>

<build>

<from>cpoepke/muledocker:latest</from>

<tags> <tag>mule-app</tag>

</tags> <command>/opt/mule-standalone-3.6.1/bin/mule -M-Dbackend.host=$BACKEND_PORT_9000_TCP_ADDR -M-Dbackend.

port=$BACKEND_PORT_9000_TCP_PORT</command>

<assembly> <mode>dir</mode>

<basedir>/</basedir>

<descriptor>assembly-app.xml</descriptor>

</assembly>

</build>

</image> 

<image> <name>rest-mock</name>

<alias>rest-mock</alias>

<run>

<ports> <port>2525:2525</port>

<port>9000:9000</port>

</ports>

<log> <prefix>Mock</prefix>

<date>ISO8601</date>

<color>yellow</color>

</log>

<wait>



<log>Server startup</log>

<url>${boot2docker.address}:2525</url>

<time>2000</time>

<shutdown>500</shutdown>

</wait>

</run>

<build> <from>cpoepke/mountebank-basis:latest</from>

<tags> <tag>rest-mock</tag>

</tags> <command>mb --configfile /mb/imposters.ejs --allowInjection</command>

<assembly>

<mode>dir</mode>

<basedir>/</basedir>

<descriptor>assembly-mock.xml</descriptor>

</assembly>

</build>

</image>

</images>

</configuration>

Você vai notar neste exemplo, o mapeamento de portas e Docker ligações

entre os dois recipientes.

Para iniciar e parar os recipientes para um teste, a seguinte configuração de

integração-teste precisa ser configurado para configurar as fases do Maven:



<executions>

<execution> <id>start</id>

<phase>pre-integration-test</phase>

<goals> 

<goal>build</goal>

<goal>start</goal>

</goals>

</execution>

<execution> <id>stop</id>

<phase>post-integration-test</phase>

<goals> <goal>stop</goal>

</goals>

</execution>

</executions>

</plugin>

Isto irá iniciar os recipientes Docker com janela de encaixe: começar antes

na fase de pré-integração-teste Maven e detê-los com janela de encaixe:

parar na fase de pós-integração-teste Maven.

Para executar o teste de integração usamos o plug-in à prova de falhas que

começa o nosso teste end-to-end do sistema na fase de integração-teste

Maven com as nossas variáveis de ambiente.



<plugin> <groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-failsafe-plugin</artifactId>


<executions>

<execution> <id>integration-test</id>

<phase>integration-test</phase>

<goals>

<goal>integration-test</goal>

</goals>

</execution>

<execution> <id>verify</id>

<phase>verify</phase>

<goals>

<goal>verify</goal>

</goals>

</execution>

</executions>

<configuration>

<systemPropertyVariables>







<system.url>http://${boot2docker.ip}:${webservice.port}</system.url>

</systemPropertyVariables>

</configuration>

</plugin>



<plugin> <groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-surefire-plugin</artifactId>


<configuration>

<skip>true</skip>

</configuration>

</plugin>

Aviso: Não para não esquecer o encaminhamento de porta no Mac e

Windows para boot2docker!

Execução de teste

A execução do teste e, portanto, a integração em um processo de integração

ou a entrega contínua pode ser iniciado emitindo os "mvn verificar"

comando. Você vê neste log, como todos os recipientes são iniciados, a

execução espera até que eles estão fazendo, executa o sistema de teste end-

to-end e como os recipientes são parou novamente:

cpoepke:sys-test cpoepke$ mvn verify

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building System Test - Mule End to End Test Demo 1.0.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

...

[INFO] --- docker-maven-plugin:0.11.5:build (start) @ sys-test ---

[INFO] Reading assembly descriptor: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/src/mai

n/docker/assembly-app.xml

[INFO] Copying files to /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/mule-a

pp/build/maven

[INFO] Building tar: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/mule-app/t

mp/docker-build.tar

[INFO] DOCKER> Created image [mule-app] "mule-app"

[INFO] DOCKER> Tagging image [mule-app] "mule-app": mule-app

[INFO] Reading assembly descriptor: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/src/mai

n/docker/assembly-mock.xml

[INFO] Copying files to /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/rest-m

ock/build/maven

[INFO] Building tar: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/rest-mock/

tmp/docker-build.tar

[INFO] DOCKER> Created image [rest-mock] "rest-mock"

[INFO] DOCKER> Tagging image [rest-mock] "rest-mock": rest-mock

[INFO]

[INFO] --- docker-maven-plugin:0.11.5:start (start) @ sys-test ---

[INFO] DOCKER> Starting container 4ee608ab49b9

[INFO] DOCKER> Creating and starting container 4ee608ab49b9 [rest-mock] "rest-mock"

2015-06-09T22:49:36.349+02:00 Mock> mountebank v1.2.122 now taking orders - point your browser to http://localhos

t:2525 for help

[INFO] DOCKER> Waited on url https://192.168.59.103:2525 and on log out 'Server startup' 2091 ms

[INFO] DOCKER> Starting container b7069c9653cd

[INFO] DOCKER> Creating and starting container b7069c9653cd [mule-app] "mule-app"

2015-06-09T22:49:38.634+02:00 Mule> MULE_HOME is set to /opt/mule-standalone-3.6.1

2015-06-09T22:49:38.642+02:00 Mule> Running in console (foreground) mode by default, use Ctrl-C to exit...

2015-06-09T22:49:38.649+02:00 Mule> MULE_HOME is set to /opt/mule-standalone-3.6.1

2015-06-09T22:49:39.845+02:00 Mule> Running Mule...

...

[INFO] DOCKER> Waited on url https://192.168.59.103:8080/api/console and on log out 'Server startup' 8114 ms

[INFO]

[INFO] --- maven-failsafe-plugin:2.18.1:integration-test (integration-test) @ sys-test ---

[INFO] Failsafe report directory: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/failsa

fe-reports

-------------------------------------------------------

T E S T S

-------------------------------------------------------

Running de.cpoepke.mule.demo.SystemIT

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.871 sec - in de.cpoepke.mule.demo.SystemIT

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO]

[INFO] --- docker-maven-plugin:0.11.5:stop (stop) @ sys-test ---

[INFO] DOCKER> Stopped and removed container b7069c9653cd [mule-app] "mule-app"

[INFO] DOCKER> Stopped and removed container 4ee608ab49b9 [rest-mock] "rest-mock"

[INFO]

[INFO] --- maven-failsafe-plugin:2.18.1:verify (verify) @ sys-test ---

[INFO] Failsafe report directory: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/failsa

fe-reports

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 21.396 s

[INFO] Finished at: 2015-06-09T22:49:50+02:00

[INFO] Final Memory: 22M/206M

[INFO] ------------------------------------------------------------------------

Conclusão

teste completo é considerado geralmente uma parte essencial de boas

práticas de desenvolvimento de software. Executando esta automatizada e

em todos os níveis da pirâmide de teste é desejado. Daí a questão de testar

um final de ponta a aplicação mula vai aparecer em algum momento. Nós

mostramos neste artigo como uma infra-estrutura de teste do sistema end-

to-end totalmente automatizado pode ser configurado. Utilizou-se para a

finalidade de testar uma aplicação Mulo de encaixe e mountebank. No

entanto, esta configuração de teste também pode ser reutilizado para outros

cenários e tipos de aplicações onde é necessário um teste end-to-end.

Internet

Mule esb teste parte 3