44

: : www.mundoj.com.br : :

Garantir a qualidade de Software tem sido um desafio prioritário nos projetos de TI. Quer seja no desenvolvimento, integração, implementação ou customização de software, o aprimoramento da qualidade é considerado uma questão primordial para toda comunidade de desenvolvimento. Testes automatizados são praticamente mandatórios para que a comunidade open-source confie e adote novos frameworks desenvolvidos. Nas últimas décadas, a pesquisa em engenharia de software tem desenvolvido normas, metodologias e técnicas para medição e garantia da qualidade de software. Grande parte destes estudos baseia-se na avaliação de qualidade interna e externa de um software. Mas o que é qualidade de software? Como garantir a qualidade de um software da maneira mais eficiente possível? Visando maximizar a qualidade de um software da maneira mais eficiente possível, este artigo tem como objetivo propor uma maneira de garantir qualidade externa através de testes automatizados com BDD utilizando ferramentas como Selenium, JBehave, Maven2 e o plugin Cargo.

Selenium, JBehave, Maven e Integração Contínua

Qualidade através de testes funcionais com

Eder Ignatowicz (me@ederig.com): Doutorando em Engenharia Elétrica na Unicamp, mestre em Engenharia Elétrica pela Unicamp (2009) e graduado em Ciência da Computação pela Universidade Estadual de Londrina (2007).Trabalha com java há mais de 3 anos e atualmente é engenheiro de Software na Dextra. Também leciona diversos cursos de graduação e pós-graduação na Faccamp e Unisal.

Rafael Farias Silva (rafaferry@gmail.com): É formado em Análise de Sistemas pela PUC Campinas em 2007. Trabalha com java há 4 anos, e possui a certificação SCEA 5. É o idealizador e principal desenvolvedor do projeto opensource Jsigner (http://code.google.com/p/jsigner/), que automatiza engenharia reversa de classes através do maven. Já participou de projetos de diversos tamanhos em várias áreas, tais como telecom, bancária, saúde etc. Atualmente é arquiteto de software na empresa NCI Soluções em Saúde.

Entenda as vantagens de desenvolver software com foco em qualidade e aprenda

através de um exemplo prático a configurar e utilizar em conjunto as ferramentas

JBehave, Selenium e Maven com objetivo de um constante acompanhamento da

qualidade através da integração contínua.

45

radativamente, a garantia da qualidade do software torna-se um tópico de extrema importância no desen-volvimento de sistemas, pois as organizações estão em

busca de vantagens competitivas e têm investido em automatizar seus processos de negócio. Tais processos mudam em um ritmo acelerado e consequentemente os softwares que suportam esses processos devem enquadrar-se a essas mudanças no menor prazo possível para garantir a satisfação dos clientes.

Um meio de conquistarmos a agilidade necessária para aten-dermos rapidamente tais mudanças é desenvolver um software de qualidade, empregando técnicas para controle de entropia e garantia de funcionamento. Desta forma, a equipe cria segurança para manter a evolução do sistema em um ritmo sustentável como é pregado pelas metodologias ágeis.

Mas como atingir tal objetivo sem causar impactos no sucesso do projeto? Como maximizar a qualidade sem comprometer o custo ou o prazo? Há como evoluirmos o software de maneira segura sem atentar para qualidade?

Com objetivo de discutir estas questões e propor uma forma de garantir a qualidade externa através de testes automatizados com BDD, este artigo está organizado da seguinte forma: na primeira seção são discutidos conceitos referentes ao triângulo da quali-dade e como as metodologias de desenvolvimento se relacionam com a qualidade de software.

Em seguida, são descritas as diferenças entre qualidade externa e qualidade interna de um software através de um exemplo prático utilizando JBehave, Selenium, Maven2 e Cargo. Baseado neste exemplo são discutidas questões como manutenibilidade de tes-tes e diferentes estratégias para realização de testes funcionais. Na última seção, são apresentadas as considerações finais, finalizando o presente artigo.

Triângulo da qualidade

O desenvolvimento de software é um processo complexo que exige um esforço colaborativo de diversos desenvolvedores trabalhando por um longo período de tempo. O produto final dificilmente será compreendido por uma única pessoa. Não importa quão boa seja a documentação, metodologia, plano de desenvolvimento etc., um projeto só será bem-sucedido se encontrarmos o equilíbrio entre as variáveis que guiam o desenvolvimento de software. Mas que variáveis são estas?

O Triângulo da Qualidade (figura 1), também conhecido como triângulo do escopo, é uma das formas de listar os trade-offs rela-cionados ao desenvolvimento de software.

Um trade-off é uma situação em que obrigatoriamente você de-verá escolher uma opção em detrimento da outra. Este princípio baseia-se no fato de que dada a ênfase em um elemento, uma menor atenção é dada aos outros elementos. No nosso caso, Cus-to, Prazo e Qualidade são os três fatores que podemos focar nossa atenção no desenvolvimento de software. Estes fatores formam os três lados deste triângulo. Por exemplo, é difícil aumentar a qualidade sem aumentar o custo, cronograma ou ambos para o software em desenvolvimento.

É possível alcançarmos alta prioridade em dois elementos do tri-

ângulo (alta qualidade em um baixo tempo de desenvolvimento, por exemplo), mas irá comprometer duramente a outra variável (irá aumentar o custo do projeto).

Figura 1. Triângulo da qualidade.

Relação entre metodologias e a qualidade de software

As metodologias atuais lidam de formas diferentes com as variá-veis do Triângulo da Qualidade. Mas de que maneira isto afeta o desenvolvimento de software?

Metodologias “não-ágeis”

As metodologias “não-ágeis” trabalham com escopo e prazo fixo e desta forma o único fator que pode variar é a qualidade. A longo prazo, esta não é uma boa estratégia, pois se não nos atentamos para a qualidade o software tende a “apodrecer”.

A correria para entregar o projeto dentro do prazo e com o escopo definido nas primeiras fases de desenvolvimento fatalmente acaba forçando as equipes a não dar a devida importância para os fatores que aumentam a manutenibilidade do software, tais como testes automatizados. Mesmo que a equipe consiga atender seus obje-tivos primários (entregar o sistema no prazo e escopo), se nada mudar, o futuro deste sistema estará comprometido.

A manutenibilidade de um software trata em responder quão fácil é a manutenção ou aperfeiçoamento de um software. Esta modi-ficação pode ser a correção de um bug, aumento de performance ou a criação de uma nova funcionalidade.

Com o software entrando em produção depois de um longo perí-odo de desenvolvimento, a tendência é que ocorram muitas solici-tações de mudança e este é o momento em que a equipe precisará demonstrar uma maior agilidade. A falta de manutenibilidade do sistema desenvolvido prejudicará os resultados, pois, desta forma, o custo de alterações no software tende a aumentar cada vez mais, o que acabará o condenando a substituição.

TIME

COST QUALITY

46

: : www.mundoj.com.br : :

Metodologias “ágeis”

A principal diferença estratégica entre as metodologias tradi-cionais e as metodologias ágeis é que a agilidade prega que a qualidade deve ser constante. Devemos progredir em um ritmo sustentável, em que a qualidade é fixa e o que varia fica a critério do cliente. Pode ser o prazo ou o escopo. Como profissionais, nós não aceitamos fazer algo sem garantia de qualidade, afinal quem paga o preço por isso é a equipe e o cliente.

Com a qualidade constante, podemos garantir que o software poderá ficar em produção o tempo que o cliente desejar, com modificações constantes, em um ritmo sustentável, previsível e sem aumento de custo para novas funcionalidades a longo prazo.

A princípio, o investimento em qualidade/testes automatizados pode parecer grande e desnecessário, mas este investimento é recompensado ao longo do projeto. Ao analisar essa questão, é preciso levar em consideração o custo de garantir o funciona-mento do sistema manualmente a cada modificação para avaliar os benefícios da automação. Uma vez que foi investido o tempo necessário para codificação do teste, ele pode ser executado infi-nitamente, enquanto que o fato da não existência do teste força a equipe a retestar manualmente partes do sistema a cada alteração.

Devemos ter em mente que o projeto não se encerra quando o sistema entra em produção. Este marco é apenas o início do ciclo de vida do software implantado em nossos clientes.

Qualidade externa VS Qualidade interna

Segundo o livro “Growing object oriented software, guided by tests”, qualidade externa é o quão bem o sistema atende a necessi-dade de seus clientes e usuários (o sistema é funcional, confiável, responsivo etc.). Por outro lado, a qualidade interna é o quão bem o sistema atende as necessidades da equipe (é fácil de modificar, entender, administrar etc.).

Como alcançar a qualidade externa

A qualidade externa é tangível através de testes de aceitação. Este tipo de teste, também conhecido como teste de caixa preta, é con-siderado por muitos autores como a atividade de teste que precede uma implantação final do sistema. Contudo, em metodologias ágeis, este teste pode ser utilizado com objetivo de garantir que cada user story entregue atenda os requisitos esperados pelos nossos clientes.

Desta forma, a definição destes testes é importante para identificar junto ao cliente o que é esperado (e realmente importante) para cada user story do sistema. Após a definição, a equipe deve imple-mentar os cenários levantados na forma de testes na camada mais externa da aplicação, que na maioria dos casos é a interface gráfica. Desta maneira, o sistema terá testes de aceitação automatizados, que demonstrarão o impacto de modificações e adições de novas funcionalidades nas histórias que já estavam implementadas.

Como alcançar a qualidade interna

É possível estabelecer uma relação direta entre manutenibilidade e qualidade interna. Neste quesito são avaliados pontos como tamanho de métodos, tamanho de classes, complexidade ciclo-mática, dependência entre pacotes etc. Para acompanhar estes fatores, existem ferramentas como o Sonar (“Evoluindo Design e Arquitetura Através das Métricas do Sonar” – MundoJ edição 43).

Uma boa maneira de garantir a qualidade interna é por meio de testes unitários construídos através de TDD (Test Driven Deve-lopment). Esta abordagem é utilizada com o intuito de escrever somente o código necessário para que os testes passem. É im-portante utilizar TDD para assegurar a qualidade interna, pois desenvolver o código de produção do ponto de vista do código cliente orienta as decisões de design, tornando o sistema mais coeso e menos acoplado.

A figura 2, extraída do livro “Growing object oriented software, guided by tests”, exemplifica a relação entre os tipos de teste e qual o tipo de qualidade assegurada.

Exemplo prático

Visando a maximização da eficiência da realização de testes, a seguir mostraremos um exemplo de teste de aceitação de uma user story utilizando as ferramentas JBehave, Selenium, Maven criando desta forma um exemplo passível de execução em um

47

ambiente de integração contínua. Este exemplo está disponível para download no site da revista MundoJ.

JBehave

JBehave é um framework java de Behaviour Driven Development. O uso do framework é bastante simples e a sua ideia principal é escrever em um arquivo-texto a user story e seus cenários. O JBehave executa linha a linha do arquivo-texto, relacionando-a a um método Java que é a materialização em código do objetivo de negócio da respectiva linha textual.

Selenium

O Selenium é uma ferramenta criada para execução de testes fun-cionais de aplicações web. Ele funciona para diversos browsers (IE, Firefox, Chrome etc.), e possui uma API capaz de abrir um browser e reproduzir todas as ações que uma pessoa executaria no uso real da aplicação. No nosso exemplo, utilizaremos a versão 1.0 do Selenium, pois a versão 2.0 ainda está em fase beta.

A integração entre o Selenium e o Jbehave é bastante interessante, pois é possível visualizar as histórias sendo executadas passo a passo junto com a sua descrição textual. O browser abre e exibe no canto superior esquerdo o passo da história que está sendo executado e em seguida é possível visualizar o Selenium mani-pulando o browser para executar o passo que está sendo exibido.

Maven/Cargo plugin

Configurando o ambiente

O Maven é uma ferramenta de build e suporte ao ciclo de vida do software já consolidada no mercado. Vamos focar no plugin cargo, que é capaz de iniciar diversos servidores, tais como Jboss, Jetty, Tomcat etc. É possível configurar este plugin para iniciar o servidor antes dos testes funcionais, executar os testes e desligar o servidor. No exemplo prático iremos mostrar a configuração deste plugin.

Caso de uso

A seguir iremos desenvolver um exemplo simples que demonstra a configuração e o funcionamento das tecnologias sugeridas em conjunto.

Para essa demonstração iremos nos basear em uma história de usuário simples conforme a seguir:

Listagem 1. História de exemplo.

Listagem 2. Classe Base dos Testes Funcionais

Narrativa:Como um administrador do sistemaDesejo incluir usuáriosPara possibilitar que outras pessoas acessem o sistema

Cenário: tentar incluir usuário com login já existenteDado que já existe usuário com nome Adam Smith e login asmith Quando administrador tenta incluir novo usuário com nome Amanda Smith e login asmithEntão o usuário não é incluído, pois já existe outro usuário com o mesmo login

public abstract class TesteFuncional extends ConfigurableEmbedder { private List<String> estorias = new ArrayList<String>(); protected static Selenium selenium = criarSelenium(); private SeleniumContext seleniumContext = new SeleniumContext(); private ConditionRunner conditionRunner = SeleniumConfiguration .defaultConditionRunner(selenium); private static Selenium criarSelenium() { selenium = new DefaultSelenium(“localhost”, 8888, “*firefox”, “http://localhost:8088/exemplo/”); selenium.start(); selenium.setSpeed(“1000”); return selenium; } public TesteFuncional() { useConfiguration(new SeleniumTestConfiguration(selenium, seleniumContext)); } /** * @param caminhoCompletoDaEstoria -> caminho para a estoria a partir * do classpath. Exemplo: br/com/mundoJ/incluir_usuario.story **/ public void adicionarEstoria(String caminhoCompletoDaEstoria) { this.estorias.add(caminhoCompletoDaEstoria); } public void adicionarPassos(Object passos) { super.addSteps(new Steps(configuration(), passos)); } @Test public void run() throws Throwable { Embedder embedder = configuredEmbedder(); embedder.runStoriesAsPaths(estorias); }}

O código-fonte deste exemplo encontra-se disponível para down-load com um guia para configuração de todos aspectos necessá-rios para a sua execução. Iremos focar no código-fonte para não poluir o artigo com detalhes de configuração. Iniciaremos pelo código do JBehave e do Selenium.

Para que as duas ferramentas funcionem integradas, é necessário criar uma superclasse para os testes funcionais. Observe a Lista-gem 2.

A classe base da Listagem 2 herda org.jbehave.core.Configurable-Embedder para que os testes sejam executados pelo JBehave. Ela possui métodos para adicionar histórias, que são arquivos-texto com a extensão .story e devem ser mantidos no classpath da aplicação. A criação do client do selenium também está mantida nesta classe, pois para configurar o JBehave é necessário passar uma instância de org.jbehave.core.configuration.Configuration e, neste exemplo, herdamos esta classe criando a SeleniumTestCon-figuration, como é possível acompanhar na Listagem 3.

48

: : www.mundoj.com.br : :

Listagem 3. Exemplo de Configuração do Selenium.

public class SeleniumTestConfiguration extends SeleniumConfiguration {

public SeleniumTestConfiguration(Selenium selenium, SeleniumContext

seleniumContext) {

super();

    doDryRun(false);

useStoryLoader(new LoadFromClasspath(this.getClass().getClassLoader()));

usePendingStepStrategy(new PendingStepStrategy() {

public void handleFailure(Throwable throwable) throws Throwable {

Assert.fail(“Passo ‘” + throwable.getMessage() + “’ nao definido!.”);

}

});

useKeywords(new LocalizedKeywords(new Locale(“PT_br”),

“jbehave-keywords”, SeleniumTestConfiguration.class.getClassLoader()));

useStoryParser(new RegexStoryParser(keywords()));

useFailureStrategy(new RethrowingFailure());

useDefaultStoryReporter(new ConsoleOutput());

useStepCollector(new MarkUnmatchedStepsAsPending());

useStepFinder(new StepFinder());

useStepPatternParser(new RegexPrefixCapturingPatternParser());

useStepMonitor(new SilentStepMonitor());

useStepdocReporter(new PrintStreamStepdocReporter());

useSelenium(selenium);

useSeleniumContext(seleniumContext);

useStepMonitor(new SeleniumStepMonitor(selenium, seleniumContext,

new SilentStepMonitor()));

}

}

public class CadastroDeUsuariosTesteFuncional extends TesteFuncional {

public CadastroDeUsuariosTesteFuncional() {

adicionarPassos(new ManterUsuariosPassos());

adicionarEstoria(“br/com/mundoj/exemplo/incluir_usuario.story”);

}

}

Com essa configuração é possível executar o cenário da Listagem 1 como um teste funcional. Neste ponto podemos identificar o papel do JBehave. Ele executa cenários escritos em qualquer idio-ma, bastando provermos no classpath um arquivo de tradução, no caso deste exemplo o jbehave-keywords.properties, para traduzir as palavras-chave do BDD, tais como Given, When, Then, Scena-rio, Narrative, entre outras.

Agora que já temos a infraestrutura pronta, podemos desenvolver a nossa classe de testes (Listagem 4).

Desta forma, o Junit é capaz de executar esta classe como um teste unitário, pois a superclasse já possui um método anotado com @Test, que executa as histórias adicionadas. Portanto para cada nova história, será criado uma nova classe de teste que apenas adiciona a história que será executada e as classes de passos, que é onde o JBehave irá procurar os métodos que devem ser execu-tados. Neste cenário, vamos verificar a implementação dos passos na classe ManterUsuariosPassos (Listagem 5).

Listagem 4. Implementação da história.

public class ManterUsuariosPassos { private Selenium selenium; public ManterUsuariosPassos() { super(); this.selenium = TesteFuncional.selenium; } @Given(“ja existe usuario com nome $nome e login $login”) public void existeUsuarioComNomeELogin(String nome, String login) { //... (codigo omitido) } @When(“administrador tenta incluir novo usuario com nome $nome e login $login”) public void incluirNovoUsuario(String nome, String login) { selenium.open(“novoUsuario.jsp”); selenium.waitForPageToLoad(“20000”); //verifica se esta na pagina correta Assert.assertEquals(“Novo usuario”, selenium.getText(“div#header h1”)); selenium.type(“nome”, nome); selenium.type(“login”, login); selenium.click(“div.buttons input#adicionar”); } @Then(“usuario nao eh incluido pois ja existe outro usuario com o mesmo login”) public void verificarLoginDuplicado() { String mensagens = selenium.getText(“ul.messages”); Assert.assertTrue(mensagens.contains(“login duplicado”)); }}

49

Através desta classe podemos visualizar (figura 3) como o JBehave funciona. Para cada linha do arquivo .story, ele busca nas classes de passos uma anotação com valor que corresponda ao texto da linha sendo executada.

Podemos observar que os métodos desta classe utilizaram o Se-lenium para manipular o browser. A API do framework é bem simples e dispensa explicações sobre o código. Ele é capaz de identificar os elementos do html de diversas formas, tais como id, seletores css, e xpath, e executar as mesma ações que um usuário humano, tais como clicar, digitar, apertar teclas de atalho, realizar drag and drop etc.

Manutenibilidade de testes

Ao adotarmos uma solução de testes funcionais baseados na in-terface gráfica devemos nos atentar para a manutenibilidade dos testes. O código de testes, assim como o código de produção, deve ser bem projetado visando a facilidade na evolução do sistema.

Pelo fato dos testes de aplicações web se basearem na estrutura do html, que pode mudar com frequência, é preciso tomar alguns

cuidados, pois uma mudança em uma única tela pode fazer di-versos testes falharem. Como mudanças na interface gráfica são frequentes, devemos nos preparar para que a correção dos testes que falharam sejam em um único ponto, facilitando a manutenção dos testes conforme o sistema evolui.

Uma alternativa para atingir este objetivo é utilizar o Design Pat-tern Page Objects1. Basicamente, a ideia deste pattern é criar uma classe para representar cada tela do sistema. O papel deste pattern é encapsular os detalhes da estrutura interna da interface gráfica (html, css, js), fornecendo para diversas classes de teste uma API única por tela.

A utilização deste pattern facilita a modificação do sistema, pois ao modificarmos um html do sistema existe apenas um ponto de manutenção nos testes, o respectivo Page Object que representa a tela modificada. Este design possibilita o crescimento do sistema coberto por testes funcionais de forma sustentável.

1http://code.google.com/p/selenium/wiki/PageObjects

50

: : www.mundoj.com.br : :

Estratégias para testes funcionais

Quando definimos a arquitetura para os testes funcionais, deve-mos nos atentar a um ponto muito importante: a preparação do contexto onde o teste será executado.

Uma possível abordagem para construção do contexto é garantir a ordem de execução dos testes, para que, por exemplo, o teste da consulta de usuário seja executado após o teste da inclusão. Dessa forma, quando o teste da consulta for executado pode-se assumir que o usuário do teste da inclusão já existirá. Outra abordagem possível é garantir que cada teste saiba preparar o contexto neces-sário para a sua execução.

Os fatores que devem ser levados em consideração para tomar a decisão de qual abordagem seguir são:

teste isolado?)-

tros testes?)-

mente o que não está funcionando?)

Analisando estes fatores, a abordagem onde cada teste sabe pre-parar o contexto para a sua execução pode ser mais trabalhosa no começo, pois a infraestrutura para configuração do contexto pode não ser simples (JDBC direto para criação dos dados necessários?, ejbs remotos?). Porém este custo inicial certamente será compen-sado, pois o desenvolvedor ganha uma ferramenta poderosa no ciclo de vida de desenvolvimento: o feedback eficiente. Utilizando esta abordagem, é possível que um único teste funcional seja exe-cutado diversas vezes, com um tempo de execução aceitável. Este rápido feedback gera confiança na equipe para modificar o projeto e executar refactorings.

Finalmente, para que seja possível executar os testes, devemos iniciar o selenium-server. Este componente é responsável pela manipulação do browser. É importante saber que é possível iniciar o selenium-server programaticamente no código do nosso teste, porém neste exemplo optamos por deixar o maven inicializar o servidor antes dos testes de integração e encerrá-lo após a execu-ção do último teste, pois desta forma o selenium-server é iniciado apenas uma vez, o que economiza tempo de execução dos testes.

Esta abordagem possui um trade off, pois embora deixar o maven responsável por inicializar o servidor diminui consideravelmente o tempo de execução da suíte de testes funcionais, para execução dos testes através de uma IDE é necessário inicializar o selenium-server manualmente. Felizmente é possível inicializar o server manualmente através do maven, executando o comando mvn selenium:start-server. Após a execução deste comando, é possível executar qualquer teste de maneira desacoplada do ciclo de vida do maven.

A configuração da Listagem 5 inicializa o selenium server na fase pre-integration-test e finaliza na etapa post-integration-test. Para entender como funciona o ciclo de vida do maven, consulte o link http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Com essa configuração o projeto está pronto para ser executado em qualquer ferramenta de integração contínua. A única ressalva é que como o teste depende do browser, o servidor de integração contínua deve possuir uma interface gráfica instalada. Essa limi-tação pode ser um empecilho, pois nem sempre temos controle sobre o ambiente onde nossa integração contínua será executada. Para contornar este problema, existe a ferramenta “xvfb2”, que

1

51

Listagem 5. Configuração Maven Selenium Server. Listagem 6. Configuração XVFB Maven.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>selenium-maven-plugin</artifactId> <version>1.0.1</version> <executions> <execution> <id>start-selenium</id> <phase>pre-integration-test</phase> <goals> <goal>start-server</goal> </goals> <configuration> <background>true</background> <port>8888</port> <singleWindow>true</singleWindow> <timeoutInSeconds>60</timeoutInSeconds> </configuration> </execution> <execution> <id>stop-selenium</id> <phase>post-integration-test</phase> <goals> <goal>stop-server</goal> </goals> <configuration> <background>true</background> <port>8888</port> </configuration> </execution> </executions></plugin>

<execution>

<id>xvfb</id>

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

<goals>

<goal>xvfb</goal>

</goals>

</execution>

Para Saber Mais

“Evoluindo Design e Arquitetura Através das Métricas do Sonar” – MundoJ edição 43.

Considerações finais

Conforme visto neste artigo, garantir a qualidade do software é um dos principais desafios no nosso dia-a-dia. Inevitavelmente sof-twares evoluem e a melhor e mais eficiente forma de administrar este crescimento é através da utilização de testes automatizados.

Contudo esta automatização é muitas vezes custosa e o retorno do investimento da automatização não é imediato. Automatizar e gerenciar os testes da forma mais eficiente possível é a resposta ao trade-off gerado pela verificação da qualidade do software e consequente aumento da qualidade do produto desenvolvido.

Esperamos com este artigo ter demonstrado uma solução para criar, manter e avaliar a qualidade externa de um software e que tenhamos esclarecido a importância da garantia da qualidade no

funciona exatamente como uma interface gráfica, porém com toda a execução em memória, sem exibir nenhuma saída na tela. Desta forma é possível executar os seus testes em um browser sem a utilização de uma interface gráfica. Outra importante vantagem do xvfb é que este lida com diferentes resoluções gráficas, expan-dindo a nossa possibilidade de testes do nosso sistema.

Para utilizar o xvfb nos testes funcionais, basta ter o software instalado no sistema operacional, e configurar o plugin selenium-maven-plugin para a inicialização da ferramenta. A Listagem 6 demonstra a configuração de mais um <execution>, que pode ser adicionado à Listagem 6 para a inicialização do servidor xvfb.

Pryce

David Thomas.

Referências

GUJ – Discussões sobre o tema do artigo e assuntos relacionados

Discuta este artigo com 100 mil outros desenvolvedores em www.guj.com.br/MundoJ