JQuery Locators no Selenium

3 de setembro de 2010 por Enium

Já expliquei aqui no blog quais são as diversas maneiras de selecionar os elementos da página com o Selenium. Mas em alguns casos, as expressões em Xpath ou CSS do Selenium ficam complicadas de serem montadas.

Vou dar um exemplo bom de quando isso acontece.

Temos a seguinte tabela em html:

<table>
	<tr>
		<td>Produto 1</td>
		<td>Produto 2</td>
		<td>Produto 3</td>
	</tr>
	<tr>
		<td>Produto 4</td>
		<td>Produto 5</td>
		<td>Produto 6</td>
	</tr>
</table>

Agora queremos validar o texto da quarta célula que é “Produto 4″.

Em Xpath, a primeira tentativa seria:
assertText | //td[4] | Produto 4

Porém isso não funciona. Como a quarta célula está na segunda linha da tabela, você tem que entrar primeiro na linha correta e usar índice 1 no td . Exemplo:

assertText | //tr[2]/td[1] | Produto 4

O mesmo ocorre com css.
Não funciona: css=td:nth-child(4)
Funciona: css=tr:nth-child(2) td:nth-child(1)

Não seria mais fácil se não precisasse usar o índice da linha?
Para isso, você terá que extender o Selenium com Jquery/Sizzle.

Por baixo dos panos o JQuery usa o Sizzle, que é uma implementação em Javascript de seletores CSS. Antigamente essa engine de css ficava dentro do próprio JQuery, mas ela foi separada para que evoluisse de forma independente.

Vou exemplificar passo a passo como configurar o Selenium IDE para usar o Sizzle:

1. Acesse http://sizzlejs.com e faça o download do arquivo zip.
2. Extraia o arquivo sizzle.js para algum diretório de sua preferência.
3. Renomeie o arquivo sizzle.js para user-extensions.js
4. Edite o final do arquivo acrescentando:

function eval_css(locator, inDocument) {
    var results = [];
    window.Sizzle(locator, inDocument, results);
    return results;
}

5. Abra a IDE e acesse Option -> Option e em Selenium Core extensions, coloque o path do arquivo editado.
6. Feche a IDE e abre-a de novo.
7. Pronto, os locators em css serão interpretados pelo Sizzle!!!

Para quem usa o Selenium RC, é só subir o selenium-server com o parâmetro “-userExtensions user-extensions.js”.

Voltando ao nosso exemplo, o comando abaixo funcionaria perfeitamente, usando apenas um índice:
assertText | css=td:eq(3) | Produto 4

Usamos o selector “eq” que faz exatamente o que precisamos. Note que o índice no Sizzle começa em 0 enquanto que no Selenium começa em 1.

Há outras funções que podem ser usadas. Dê uma olhada na documentação do Sizzle.

A boa notícia é que o Selenium irá trocar a api atual (cssQuery) que interpreta CSS locators para usar o Sizzle. Então na próxima versão, você não precisará mais alterar o user-extensions.js para sobrescrever o comportamento dos locators css.

Perguntas e Respostas sobre Selenium

25 de agosto de 2010 por Enium

Para quem não conhece, foi criada uma área no StackExchange dedicada 100% ao Selenium. É um site de perguntas e respostas, e o grande lance é que geralmente as perguntas e respostas são de alta qualidade, já que muito expert no assunto participa.
O site ainda está na fase de commitment, e isso quer dizer que precisa atingir um certo número de usuários comprometidos a fazer perguntas e respostas para passar para a próxima fase. Quando isso acontecer, o site finalmente será liberado para perguntas e respostas. Hoje a taxa de commitment está em 22%, precisamos chegar nos 100%.
Se você acho o Selenium muito legal e tem interesse em contribuir para a comunidade, inscreva-se agora!!
http://area51.stackexchange.com/proposals/4693/selenium

O único problema é que o site é em inglês. Se você não se sente confortável em ler e escrever em inglês, tire suas dúvidas em português na parte de Dúvidas do blog.

Ajude a divulgar essa ideia!!!

Autenticação HTTP básica e Selenium

14 de maio de 2010 por Enium

Recentemente, um dos leitores do blog me perguntou como automatizar um teste quando o sistema tem uma autenticação HTTP básica e achei interessante compartilhar com vocês.

Exemplo de autenticação HTTP básica

Não há nada específico para o Selenium, mas sim sobre o protocolo HTTP.
Segundo a RFC 1738 que descreve como devem ser escritas as URLs, você pode definir o usuário e senha diretamente no endereço que deseja acessar. Exemplo:

http://usuario:senha@www.seusite.com/home.html

Aparentemente, isso deveria funcionar para todos os browsers, já que é um padrão. Mas no Internet Explorer não vai funcionar. Isso porque o Windows desabilita essa autenticação por medidas de segurança. Mas como para testar no IE você tem que subir o Selenium Remote Control, isso não será um problema já que o próprio RC altera o registro do Windows habilitando essa funcionalidade. Para maiores informações você pode dar uma olhada aqui.

Portanto, no seu teste automatizado, você teria que usar o comando open e alterar a URL desejada para conter os dados de acesso:

open | http://usuario:senha@www.seusite.com/home.html

Até a próxima :)

Screenshot com Selenium – Parte 2, TestNG

23 de abril de 2010 por Enium

Há um tempo atrás escrevi um post demonstrando como dar print screen com Junit, Maven e Selenium se houvesse algum erro no teste.
Recentemente, um dos leitores do blog me perguntou se era possível fazer o mesmo só que usando o TestNG.
Como eu não uso muito o TestNG, eu não sabia se isso era possível, e fui atrás da documentação do TestNG e a do plugin Surefire do maven.

Para fazer isso, você terá que extender a classe TestListenerAdapter e implementar o método onTestFailure que será invocado após qualquer exceção disparada.

Deve ficar mais ou menos assim:

import org.testng.ITestResult;
import org.testng.TestListenerAdapter;
import com.thoughtworks.selenium.DefaultSelenium;
 
public class ScreenshotListener extends TestListenerAdapter
{
 
    public void onTestFailure(ITestResult result)
    {        
        try {
 
            AbstractTestCase testCase = (AbstractTestCase) result.getTestClass().getInstances(false)[0];
 
            DefaultSelenium selenium = testCase.getSelenium();
            if (selenium != null) {
                String fileName = System.getProperty(
                        "screenshots.dir", "/tmp")
                        + "/" + result.getTestClass().getName() + "-" + result.getName() + ".png";
                System.out.println("Capturando erro em: " + fileName);
                selenium.captureEntirePageScreenshot(fileName, "background=#FFFFFF");
            }
 
        } catch (Exception e2) {
            System.err
                    .println("Não foi possível capturar o screenshot");
        }
    }
}

Outro passo necessário é configurar o plugin surefire e informar o listener a ser usado:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<properties>
			<property>
				<name>listener</name>
				<value>br.com.seuenium.ScreenshotListener</value>
			</property>
		</properties>
	</configuration>
</plugin>

Pronto.

Que tal integrar esse código com o exemplo de paralelização em testes do Selenium com TestNG descritos nesse post?

Como eu sou bonzinho, já deixei isso pronto. Pode baixar o exemplo AQUI e depois rode o comando mvn clean install.

Até a próxima.

Testes unitários com EasyMock e JUnit – Introdução

13 de abril de 2010 por leandro

A partir de agora, o Blog do Seu Enium terá a participação de um novo colaborador. Seu nome é Leandro, mais conhecido como Mendigo, e trabalhamos juntos no UOL.

Para iniciar a participação dele no blog, ele vai falar um pouco sobre uma biblioteca que auxilia bastante na hora de efetuar testes unitários com java: EasyMock.

Esta biblioteca permite que nós criemos objetos de um determinado tipo (classe ou interface), para podermos isolar a classe a ser testada.

Mas por que fazer isso? Bom, quando estamos testando de forma unitária, é interessante que foquemos somente na classe, ou mesmo somente em um método da classe. Porém, em um projeto orientado à objetos, o que temos, idealmente, é um conjunto de classes efetuando tarefas específicas e interagindo entre si. A grande maioria das classes possui dependências em relação à outras classes. É importante que o grau de dependência (ou acoplamento) seja baixo, para que alterações em dependências não afetem drasticamente a classe dependente, mas esse acoplamento dificilmente será zero (nesse caso teríamos uma classe inchada, fazendo muita coisa, e difícil de manter).

Por exemplo, vamos considerar uma classe que leia informações de uma fonte de entrada, e escreva informações em um destino. Além disso, essa classe é capaz de interpretar alguns comandos básicos para manipular os dados de entrada (neste primeiro exemplo a classe sabe somente enviar a hora atual).

(o código do exemplo está disponível aqui)

Processor

package foo;
 
public class Processor
{
 
   private Source source;
   private Destination destination;
 
   public Processor( Source source, Destination destination ) {
      this.source = source;
      this.destination = destination;
   }
 
   public void process() {
      String input = null;
      try
      {
         input = source.read();
      }
      catch (Exception e)
      {
 
      }
 
      if( input != null ) {
         String output = transform( input );
 
         try
         {
            destination.write( output );
         }
         catch (Exception e)
         {
            throw new ProcessorException("Nao foi possível enviar os dados");
         }
      }
   }
 
   private String transform(String input)
   {
      if( "[[Time]]".equals( input ) ) {
         return "time: " + System.currentTimeMillis();
      }
      return input;
   }
}

Source

package foo;
 
public interface Source
{
 
   String read();
 
}

Destination

package foo;
 
public interface Destination
{
 
   void write(String output);
 
}

Para complicar um pouco, vamos considerar que Source obtém os dados de um banco de dados e que Destination envia os dados escritos pela rede. Dessa foram para testarmos a classe Processor, seria necessário acessar um banco de dados e enviar dados pela rede.

Em testes de integração ou de sistema, isso está OK, mas em testes de unidade não. Estes deveriam ser isolados, contidos, não condicionados à disponibilidade ou não dos recursos externos como rede ou banco. Além disso, eles deveriam rodar de forma muito rápida, para não atrasar o processo de build e de desenvolvimento.

Com o EasyMock podemos criar um objeto que se passe por um Source, mas que não acessa realmente o banco de dados, e um outro que emule o comportamento de um Destination, sem efetivamente enviar dados pela rede, isolando assim a nossa “unidade” (Processor) e tendo um controle total sobre os mocks (Neste post estou chamando tudo de mock, porém há algumas implicações “técnicas” nesta nomenclatura, e para quem quiser se aprofundar melhor, sugiro este texto: http://martinfowler.com/articles/mocksArentStubs.html)

Vamos escrever um teste para o fluxo mais básico do nosso Processor.

package foo;
 
import org.easymock.EasyMock;
import org.junit.Test;
 
public class ProcessorTest
{
 
   @Test
   public void testProcess()
   {
      // Criação dos mocks e configurando o comportamento esperado
      Source source = EasyMock.createMock(Source.class);
      Destination destination = EasyMock.createMock(Destination.class);
 
      EasyMock.expect(source.read()).andReturn("SeuEnium");
      destination.write("SeuEnium");
 
      EasyMock.replay(source, destination);
 
      // Testando a nossa "unidade"
      Processor processor = new Processor(source, destination);
 
      processor.process();
 
      // Verificando o comportamento
      EasyMock.verify(source, destination);
   }
 
}

Neste teste podemos ver um esquema básico de utilização de mocks:

    1. Criação dos mocks – a forma mais simples é a ilustrada no exemplo: EasyMock.createMock( Source.class )
      Este método irá criar um mock do tipo especificado (Classe ou Interface) – O EasyMock é capaz de criar mocks tanto de classes quanto de interfaces (neste exemplo vamos lidar somente com interfaces)
      Comportamento esperado – os mocks são criados em um estado de gravação – tudo o que for feito com o objeto até a chamada de EasyMock.replay( source ) será gravado internamente pelo EasyMock, e esse comportamento será depois validado.
      Como podemos ver no exemplo, utilizando EasyMock.expect( source.read() ) estamos dizendo ao EasyMock que é esperada uma chamada ao método read do mock, e que esta chamada deve retornar a String “SeuEnium”. Porém, como podemos ver em destination.write("SeuEnium"), não é necessário utilizar EasyMock.expect para mockar uma chamada (neste caso não é nem possível, pois o método write é void, e ocorrerá um erro de compilação caso se tente mockar write utilizando EasyMock.expect). O uso de EasyMock.expect se faz necessário quando queremos especificar um valor de retorno para o método mockado.
      Para indicar ao EasyMock que já configuramos o comportamento do mock e que a partir deste momento o objeto deve se comportar realmente como um objeto “normal”, utilizamos EasyMock.replay( source, destination ). A partir deste ponto, não é mais possível efetuar chamadas a EasyMock.expect, a não ser que se utilize EasyMock.reset( source ).
      Execução do teste da “unidade” – aqui vamos fazer o teste propriamente dito e efetuar quaisquer verificações de resultado da unidade testada.
      Verificação do comportamentoEasyMock.verify( source, destination ) diz ao EasyMock para verificar se os métodos esperados foram chamados – se o comportamento esperado não for satisfeito, o EasyMock irá disparar um exceção, fazendo o teste unitário falhar.

O EasyMock oferece uma grande flexibilidade na especificação do comportamento dos mocks, o que permite que sejam testados muitos cenários que de outro modo seriam difíceis de testar – por exemplo, vamos supor que queremos verificar que nosso Processor se comporte de uma determinada maneira quando ocorrer um problema ao ler do banco de dados. Podemos dizer ao EasyMock para disparar uma exceção no momento de leitura, e verificar o comportamento do Processor quando isso acontece.

   @Test
   public void testProcessWhenReadFails() {
      // Criação dos mocks e configurando o comportamento esperado
      Source source = EasyMock.createMock(Source.class);
      Destination destination = EasyMock.createMock(Destination.class);
 
      // Especificando o disparo de uma exceção
      EasyMock.expect(source.read()).andThrow(new RuntimeException("Erro na leitura"));
 
      EasyMock.replay(source, destination);
 
      // Testando a nossa "unidade"
      Processor processor = new Processor( source, destination );
 
      processor.process();
 
      // Verificando o comportamento
      EasyMock.verify(source, destination);
   }

Neste código estamos testando que Processor nunca irá tentar escrever os dados pela rede quando houver uma exceção na leitura dos dados – Como não configuramos nenhum comportamento para destination, qualquer chamada a métodos desse objeto irá disparar uma exceção.

Digamos agora que gostaríamos de testar o comportamento de Processor quando ocorrer um erro ao escrever pela rede. Neste caso, gostaríamos que uma exceção fosse lançada pelo próprio Processor, para notificar o erro.

   @Test(expected=ProcessorException.class)
   public void testProcessWhenWriteFails() {
      // Criação dos mocks e configurando o comportamento esperado
      Source source = EasyMock.createMock(Source.class);
      Destination destination = EasyMock.createMock(Destination.class);
 
      // Especificando o disparo de uma exceção
      EasyMock.expect(source.read()).andReturn("SeuEnium");
      destination.write("SeuEnium");
      EasyMock.expectLastCall().andThrow( new RuntimeException("Erro na escrita") );
 
      EasyMock.replay(source, destination);
 
      // Testando a nossa "unidade"
      Processor processor = new Processor( source, destination );
 
      processor.process();
   }

Um outro ponto em que o EasyMock oferece flexibilidade é na verificação dos parâmetros passados para as chamadas ao mock. Por padrão, o EasyMock irá utilizar o equals() para verificar se o parâmetro fornecido é o mesmo que foi configurado como esperado. Porém, algumas vezes esse comportamento pode ser restritivo, e o EasyMock oferece formas para mudarmos a maneira como ele irá verificar os parâmetros.

Por exemplo, o no processor sabe interpretar o comando “[[Time]]”. Quando essa String é recebida, o processor envia pela rede o tempo em milissegundos atual. Da maneira como está implementado, o tempo enviado irá ser diferente a cada execução do teste. Há diversas maneiras de testar este tipo de comportamento, e a que vamos utilizar aqui não é a melhor delas, mas ela ilustra o conceito. Vamos utilizar um regexp para validar se foi enviado o tempo para o destino.

   @Test
   public void testProcess2() {
      // Criação dos mocks e configurando o comportamento esperado
      Source source = EasyMock.createMock(Source.class);
      Destination destination = EasyMock.createMock(Destination.class);
 
      // Especificando o disparo de uma exceção
      EasyMock.expect(source.read()).andReturn("[[Time]]");
      destination.write( EasyMock.matches( "time: \\d+" ) );
 
      EasyMock.replay(source, destination);
 
      // Testando a nossa "unidade"
      Processor processor = new Processor( source, destination );
 
      processor.process();
   }

Bom pessoal, essa foi uma introdução ao uso do EasyMock para facilitar testes de unidade. No próximo post, vamos dar uma olhada em um exemplo um pouco menos vago, e vamos ver como efetuar mock de classes realmente, e não somente de interfaces.

Um abraço.

Novos recursos do Selenium Grid

17 de março de 2010 por Enium

Saiu ontem a versão 1.0.5 do Selenium Grid, e com ela veio uma das funcionalidades mais esperadas: o gerenciamento dos Remote Controls conectados ao hub.

Antes, se um Remote Control (RC) estivesse fora por algum motivo inesperado, ele continuava disponível no hub, o que fazia com que se algum cliente tentasse se conectar a esse RC ele receberia um erro.

Agora, se um RC está fora do ar, ele sai automaticamente da lista de RCs disponíveis. Essa retirada pode ocorrer por três diferentes motivos:

  • Se um cliente solicita uma sessão ao Hub e ao tentar reservar um RC, esse RC está indisponível
  • Se o RC não responder a uma chamada periódica do hub para verficar se o RC está vivo. Esse mecanismo se chama hearbeat mechanism, que traduzindo é uma checagem do batimento cardíaco. A frequência dessa checagem é de 3 minutos. Você pode alterar esse valor no grid_configuration.yml usando a propriedade remoteControlPollingIntervalInSeconds
  • Se uma sessão do RC está idle por mais de um tempo configurável. O valor default é a cada 5 minutos e você pode alterar isso no grid_configuration.yml usando a propriedade sessionMaxIdleTimeInSeconds

Outro cenário que poderia ocorrer e que foi corrigido é se você tivesse que reiniciar o hub, você perderia todos os RCs conectados a ele. Foi criada uma configuração para que cada RC pingue o hub a cada X segundos configuráveis. Com isso você pode reiniciar o hub e é só uma questão de segundos até que todos os RCs disponíveis voltem a ficar disponíveis para serem usados. A frequência dessa checagem é a cada 30 segundos, mas você pode alterar isso ao iniciar o RC:

ant -DhubPollerIntervalInSeconds=120 launch-remote-control

É claro que todas essas checagens consomem recursos da máquina e da rede, mas vale muito a pena, já que antes não havia nenhum gerenciamento e era uma dor de cabeça quando você tinha algum problema de RCs indisponíveis ou travados.

Para mais informações leia essa documentação em inglês.

Outra notícia que saiu, é que o mantenedor do projeto opensource do Selenium Grid irá mudar. O desenvolvedor atual está sem tempo e sem prioridades para manter o projeto e está em busca de um sucessor. Para ler mais sobre isso acesse aqui.

Até a próxima.

Evoluindo seus testes em Selenium com PageObjects

9 de março de 2010 por Enium

Já faz um tempo que queria falar sobre esse assunto mas estava esperando para o blog ter mais conteúdo e mais acesso.

Quem desenvolve testes com o Selenium já notou que a IDE é só para vender o peixe. É lindo acreditar que criar teste automatizado é só ligar o botão de gravação, sair navegando pelas páginas e salvar os arquivos para uma próxima execução. Tudo parece perfeito até o momento em que você precisa dar manutenção nos seus testes.
O padrão de PageObjects ajuda em:

  • Manutençao do código
  • Clareza no código
  • Reuso de funcionalidades
  • Organização dos testes

A ideia do padrão é criar classes para cada tela do seu sistema para que ela contenha as funcionalidades da própria e encapsule a lógica dos comandos do Selenium.

Vamos para um exemplo prático.

Criei uma página com a funcionalidade de uma busca.

Tela de busca

Vamos criar uma classe representando a tela de busca e suas funcionalidades:

package br.com.seuenium;
 
import com.thoughtworks.selenium.DefaultSelenium;
 
public class TelaBusca {
 
	private DefaultSelenium selenium;
 
	public TelaBusca(DefaultSelenium selenium) {
		this.selenium = selenium;
	}
 
	public void abrir() {
		selenium.open("/testes/8-pageobjects/buscar.php");
	}
 
	public void buscar(String termo) {
		selenium.type("name=q", termo);
		selenium.click("//input[@type='submit']");
		selenium.waitForPageToLoad("10000");
	}
 
}

O construtor da classe recebe o objeto DefaultSelenium para poder acessar os comandos da api. Os dois métodos criados representam as funcionalidades da tela: o primeiro que é abrir a própria página e o segundo que é buscar por um determinado termo. Note que a lógica do Selenium de digitar o termo no campo e em seguida clicar no botão de submit foi encapsulada pelo método buscar.

Agora vamos criar o nosso caso de teste. A ideia do teste é buscar pelo termo “Selenium” e depois validar que o termo continua presente na caixa de busca. A tela vai ficar assim:

Tela de resultado de busca

E o TestCase:

package br.com.seuenium;
 
import org.junit.*;
 
import com.thoughtworks.selenium.DefaultSelenium;
 
public class BuscaTestCase {
 
	private DefaultSelenium selenium;
 
	@Before
	public void start() {
		selenium = new DefaultSelenium("localhost", 4444, "*firefox",
				"http://www.seuenium.com.br");
		selenium.start();
	}
 
	@Test
	public void testSucesso() {
 
		TelaBusca tela = new TelaBusca(selenium);
 
		tela.abrir();
		tela.buscar("Selenium");
 
		//validacoes
		Assert.assertEquals("Selenium", tela.carregarTermoBuscado());
	}
 
	@After
	public void stop() {
		selenium.stop();
	}
}

Note que o método “testSucesso” instancia a classe TelaBusca, chama o método “abrir” e depois o “buscar”. Em seguida vêm as validações, que por enquanto é só uma. O testCase dá um asserEquals do termo “Selenium” com o método “carregarTermoBuscado” que ainda não foi implementado. Vamos implementá-lo:

package br.com.seuenium;
 
import com.thoughtworks.selenium.DefaultSelenium;
 
public class TelaBusca {
 
	private DefaultSelenium selenium;
 
	public TelaBusca(DefaultSelenium selenium) {
		this.selenium = selenium;
	}
 
	public void abrir() {
		selenium.open("/testes/8-pageobjects/buscar.php");
	}
 
	public void buscar(String termo) {
		selenium.type(localizadorDoCampoDoTermo(), termo);
		selenium.click("//input[@type='submit']");
		selenium.waitForPageToLoad("10000");
	}
 
	public String carregarTermoBuscado() {
		return selenium.getValue(localizadorDoCampoDoTermo());
	}
 
	private String localizadorDoCampoDoTermo() {
		return "name=q";
	}
 
}

Note que o método foi implementado e também houve um pequeno refactoring. Tanto o método “carregarTermoBuscado” como o “buscar” compartilhavam um mesmo locator que correspondia ao input text do termo. Foi criado o método “localizadorDoCampoDoTermo” para evitar duplicidade e facilitar a manutenção do teste. Caso o campo mude de nome no futuro, você apenas terá que alterar esse método e não ficará caçando em seus testes quem usa esse campo. A mesma ideia poderia ser aplicada ao locator do botão buscar.

Continuando com as validações, vamos conferir se a tela retornou os 2 resultados esperados.

Vamos adicionar a seguinte validação no TestCase:

List<String> resultadosEsperados = Arrays.asList(
	"Selenium IDE is a Firefox add-on that records clicks, typing, and other actions to make a test, which you can play back in the browser.",
	"Selenium is a chemical element with the atomic number 34, represented by the chemical symbol Se, an atomic mass of 78.96.");
Assert.assertEquals(resultadosEsperados, tela.carregarResultados());

E na classe da tela vamos implementar o método que retorna a lista de resultados:

public List<String> carregarResultados() {
	List<String> resultados = new ArrayList<String>();
	Integer xpathCount = selenium.getXpathCount(localizadorDosResultados()).intValue();
	for (int i = 1; i <= xpathCount; i++) {
		resultados.add(selenium.getText(localizadorDosResultados()+"["+i+"]"));
	}
	return resultados;
}

Bom gente, esse exemplo é bem simples, mas já da pra ver os ganhos em usar PageObjects.

Você pode fazer o download aqui de um projeto maven com os testes desse post.

Há outros tópicos sobre PageObjects que pretendo falar em outros posts. Para quem não sabe, vai sair uma versão nova do Selenium, a 2.0, e ela tem suporte nativo para PageObjects. Esperem o próximo post para ler mais sobre o Selenium 2.0. Aguardem!!!

Capturando a tela com o Selenium e Junit

4 de janeiro de 2010 por Enium

Uma das coisas que notei usando Selenium é que as vezes você fica perdido quando um teste falha.
Nem sempre a mensagem de erro retornada pelo Junit ou pelo Selenium é suficiente para entender o porquê de um teste falhar.
A imagem do browser na hora em que houver uma falha pode te auxiliar na detecção do verdadeiro erro do seu teste ou sistema.

O Selenium possuí 2 comandos para dar screenshot:

1- captureScreenshot(String fileName)

Esse comando captura toda a tela. É como se você desse um print screen com o teclado.
Ficaria mais ou menos assim:

Tela Inteira

2- captureEntirePageScreenshot (String filename, String kwargs);

Esse comando captura toda a página que está no browser.
A imagem ficaria assim:

Página Inteira

O benefício do captureScreenshot é que funciona em todos os browsers. Em compensacão, se sua página é muito grande, ou seja, você precisa usar a barra de rolagem para ver a página inteira, a imagem gerada apenas conterá a parte visível. Com o captureEntirePageScreenshot esse problema não acontece, mesmo que a página tenha scroll, a imagem final será da página completa. O contra do captureEntirePageScreenshot é que ele só funciona nativamente no Firefox. Para funcionar no IE, você precisa instalar uma ferramenta http://snapsie.sourceforge.net.

Agora que você já sabe qual o comando para tirar screenshot com o Selenium, vamos agora aprender a tirar o screenshot apenas quando seu teste em Junit der erro.
Para isso você vai ter que usar a versão 4.7 ou mais recente do Junit.

Primeiro você precisa criar uma classe que implemente a interface MethodRule. Depois você precisa implementar o método apply com a lógica de chamar o comando de capturar a tela. A classe ficaria mais ou menos assim:

package br.com.seuenium;
 
import org.junit.rules.MethodRule;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.Statement;
 
import com.thoughtworks.selenium.Selenium;
 
public class ScreenshotRule implements MethodRule {
 
  public Statement apply(final Statement statement, 
               final FrameworkMethod frameworkMethod, final Object testCase) {
    return new Statement() {
 
      public void evaluate() throws Throwable {
        try {
          statement.evaluate();
        } catch (Throwable e) {
 
          try {
            ExemploTest exemploTest = (ExemploTest) testCase;
            Selenium selenium = exemploTest.getSelenium();
            if(selenium != null) {
              String fileName = "/tmp/image.png";
              selenium.captureEntirePageScreenshot(fileName, "");
            }
 
          } catch (Exception e2) {
            System.err.println("Não foi possível capturar o screenshot");
          }
 
          throw e;
        }
      }
 
    };
  }
 
}

Esse código chama o método evaluate do statement que corresponde à execução de um método anotado com @Test. Se retornar uma exceção, o comando de capturar a tela é acionado.

Em seguida, na sua classe de teste, você deve criar um atributo público do tipo ScreenshotRule e deve inicializá-lo na própria declaração e anotá-lo com @Rule.
Deve ficar mais ou menos assim:

package br.com.seuenium;
 
import junit.framework.Assert;
 
import org.junit.After;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
 
import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;
 
public class ExemploTest {
 
  private Selenium selenium;
 
  @Rule
  public ScreenshotRule screenshotRule = new ScreenshotRule();
 
  @Before
  public void start(){
    selenium = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.seuenium.com.br");
    selenium.start();
  }
 
  @After
  public void stop(){
    selenium.stop();
  }
 
  @Test
  public void testErro() {
    selenium.open("/testes/7-screenshot/teste.php");
    Assert.assertEquals("Hello World", selenium.getText("id=inexistente"));
  }
 
  @Test
  public void testSucesso() {
    selenium.open("/testes/7-screenshot/teste.php");
    Assert.assertEquals("Hello World", selenium.getText("id=existente"));
  }
 
  public Selenium getSelenium() {
    return selenium;
  }
 
}

Eu criei um projeto maven pronto para ser executado. Basta fazer o download aqui.
Descompacte o arquivo, entre no diretório e execute “mvn clean install”. O testErro irá falhar e você poderá ver o screenshot em target/testErro.png.

Bom, é isso pessoal. Qualquer dúvida mandem um comentário.
Até a próxima.

Benefícios em usar CSS locators no Selenium

4 de novembro de 2009 por Enium

Olá garotada, o velhinho voltou.

Desculpem-me. Estive ausente por um tempinho me dedicando a outros projetos pessoais. Gostaria de agradecer a todos que entraram em contato por email ou pelo blog nesse período de ausência. Não desanimei não, estou de volta :)

Resolvi falar sobre algo que vale a pena dar uma olhada. Vocês tirem as suas conclusões heheh!!!!

Se você não sabe o que é um locator, dê uma olhada no seguinte post: “Encontrando os elementos de uma página com o Selenium”

Os princípais benefícios em usar css locators são:

  1. Expressões sucintas
  2. Teste menos sensível à alteração de template
  3. Performance nos browsers
  4. Os webmasters conhecem bem CSS locators

Vamos tomar como base o seguinte código html que descreve o menu de uma página qualquer:

<div id="menu">
 <ul>
  <li class="first">Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
 </ul>
</div>

O locator mais comum e o mais usado é o xpath. Com ele você consegue selecionar praticamente tudo da página. Mas em muitos casos ele pode não ser o ideal. Imagine que temos que fazer um teste de verificar o texto do primeiro elemento do menu. O locator em xpath para esse caso seria:

xpath=//div[@id='menu']//li[@class='first']

O locator em xpath não ficou tão simples. Agora usando css locator ficaria assim:

css=#menu .first

Bem mais simples, mais sucinto, não? Essa é a sintaxe do css. Para mais informações sobre a sintaxe você pode dar uma olhada aqui

Falando agora do segundo benefício, imagine que surgiu a necessidade de zebrar o menu. Para quem não conhece, zebrar significa alternar as cores. No nosso exemplo, as linhas pares passam a ter cores diferentes das linhas ímpares; questões de usabilidade :) Para fazer isso, as linhas ímpares do menu passaram a ter um css novo “odd” e as linhas pares “even”. O html ficou assim:

<div id="menu">
 <ul>
  <li class="first even">Item 1</li>
  <li class="odd">Item 2</li>
  <li class="even">Item 3</li>
 </ul>
</div>

Se você usar o mesmo locator em xpath do exemplo anterior para selecionar o primeiro item do menu, não funcionaria. Isso porque o locator em xpath dá match nos textos, não levando em conta o contexto css. Se você ama xpath, você teria que alterar o locator para passar no seu teste, ficando assim:

xpath=//div[@id='menu']//li[contains(@class,'first')]

Foi necessário usar a funcão “contains” que verifica se a string do atributo class contém o texto “first’.

Por outro lado, o css locator do exemplo anterior não quebraria com esse novo html. Ele funcionaria sem modificação alguma. Muito bom!!!!!!!!!!!!!!

Outro benefício é a performance da execução das expressões em css nos browsers. O css é resolvido muito mais rápido do que as expressões em xpath, já que todos os browsers possuem suporte nativo para css.
Além disso, você já deve ter notado que seus testes demoram muito mais para serem executados no IE do que no Firefox. Isso porque o IE demora muito mais para avaliar as expressões em XPath do que o Firefox. Se você usar css locators, seus testes no IE irão ser executados mais rápido. Boa dica, hein?!

Por último, os webmasters tiram de letra a sintaxe do css locator. Além de eles conhecerem bem de CSS, eles usam bastante essas expressões para selecionar elementos da página via JQuery. Portanto, se você está quebrando a cabeça para definir o locator ideal para o seu comando, vá buscar ajuda com um webmaster.

Bom galera, é isso.

Voltarei a postar em breve também. Não desistam do velhinho do Seu Enium heehhe!!! Até a próxima e deixem seus comentários. Valeu!!!!!

Novos comandos do Selenium para gerar CPF e CNPJ

20 de maio de 2009 por Enium

Um dos leitores do blog, Maurício Avellar, teve uma iniciativa muito boa.
Ele resolveu compartilhar com todos alguns comandos criados por ele que provavelmente serão úteis para outras pessoas.

Os comandos criados pelo Maurício dão a possibilidade de você inserir um CPF ou um CNPJ válidos em qualquer input na tela.

A sintaxe dos comandos é a seguinte:

| generateCNPJ | locator |
| generateCPF | locator |

O único parâmetro é o locator que deve corresponder ao input que você quer inserir o novo valor.

O arquivo de extensões do Selenium que contém os novos comandos, você pode fazer o download aqui.

Para você usá-los na IDE, siga os seguintes passos:

  1. Abra a Selenium IDE e clique em Options >> Options.
  2. Altere a opção “Selenium Core extensions (user-extensions.js)” para apontar para o arquivo js que você acabou de baixar.
  3. Aperte o botão OK.
  4. Feche a IDE e abre-a novamente para que os comandos novos sejam carregados.

Pronto, você já pode usar os comandos nos seus testes.

Muito obrigado Maurício pela sua colaboração.

Quem quiser compartilhar qualquer outro comando ou experiências só entrar em contato.

:)