A chave de tudo está no método waitForCondition do Selenium que como o próprio nome  já diz, faz a execução aguardar até que determinada condição seja satisfeita. Utilizaremos o waitForCondition para aguardar até não existirem requisições AJAX pendentes, a forma de fazer isso depende do framework que você utiliza:

JQuery : jQuery.active

ExtJS: Ext.Ajax.isLoading()

Dojo Toolkit: dojo.io.XMLHTTPTransport.inFlight.length

Prototype: Ajax.activeRequestCount

O waitForCondition recebe dois parâmetros: a condição e o tempo em milissegundos de tolerância para a resposta (timeout). Note que como o comando roda por padrão na janela do test runner e não na da aplicação precisamos usar o snippet JavaScript “selenium.browserbot.getCurrentWindow()”. Na tabela Selenese abaixo armazenamos a implementação específica de framework na variável requisicoesAJAX:

Se você usa ruby, a gem selenium-client possui o método wait_for_ajax com implementações para Prototype (padrão) e jQuery. O framework é configurável na instanciação:

Outra opção é escrever seu próprio método (no meu caso deixo isso nas definições de passos do Cucumber):

Você conhece formas de fazer isso para outros frameworks JavaScript? Seja bem vindo a sugerir nos comentários 

<a href="#" class="popup" title="Veja o popup!"
  titulo_do_popup="Titulo para o popup">Clique-me</a>
   

Um dos mitos do HTML é que ao utilizarmos atributos fora da especificação estamos tornando nosso código não padrão. Mito esse que inclusive precisou ser rebatido pelo pessoal do Dojo Toolkit que usa esse recurso extensivamente.

Custom attributes have always been valid HTML [...] The HTML specification states that any attribute not recognized is to be ignored by the HTML rendering engine in user agents, and Dojo optionally takes advantage of this to improve ease of development.

Como essa é uma necessidade recorrente, o HTML 5 propõe a utilização de atributos prefixados com ‘data-’ conforme a sessão Custom data attribute da especificação

Já o XHTML (por ser XML) é bem chato no que diz respeito a isso: se um atributo não está nas especificações então seu código é considerado não padrão pois o mesmo é validado contra um DTD. Uma alternativa para quem não pode fugir do XHTML é definir o metadado através de JSON por convenção indexado por id:

<script type="text/javascript">
var titulos_de_popups = {link1: "Titulo 1", link2: "Titulo 2"};
</script>
<a href="#" title="Veja o popup!" id="link1">Clique-me</a>

Utilizar atributos não padrões para metadados é algo que vai da necessidade e possibilidade de cada um, contudo, muito cuidado: já cheguei a ver atributos não padrões armazenando instruções SQL inteiras, algo totalmente abominável (mesmo que os atributos fossem padrões ).
Quando estiver precisando passar metadados demais dessa forma sinta o mal cheiro: algo está muito errado na sua aplicação.

—– Atualização —–

Pra quem usa jQuery, esse plugin facilita bastante a recuperação dos metadados.

Desenvolvedores escrevendo testes de aceitação por eles mesmos, para eles mesmos

Testes de aceitação são para colaboração e comunicação. Usá-los apenas para testes é subutilizar o potencial. Todos os interessados na funcionalidade devem estar envolvidos na construção dos testes de aceitação.

Testes de aceitação escritos em nível unitário

Testes unitários são específicos da implementação enquanto que testes de aceitação não são. Testes de aceitação expressam objetivos de negócios, enquanto que testes unitários expressam, tecnicamente, objetivos de dada implementação.

Escrever os testes após o código estar pronto

Escrever testes de aceitação após o código estar escrito não traz benefícios suficientes comparado a escrevê-los antes e deixá-los guiar o desenvolvimento.

Esconder dados de testes em fixtures

Esconder dados que afetam o comportamento testado é uma má idéia. Estamos falando sobre comunicação: certifique-se que seus testes comunicam o objetivo ( dados de teste fazem parte do teste ).

Testes dependentes de detalhes de implementação e estruturas dos dados

Testes de aceitação precisam ser independentes de plataforma, tecnologia e implementação. Se daqui a uns anos você decidir portar a aplicação para uma nova tecnologia ou arquitetura, com poucas alterações em fixtures deve ser possível rodar os testes de aceitação contra o novo sistema.

O objetivo desse post é mostrar como configurar o Cucumber para utilizar Webrat em modo Selenium quando conveniente com reaproveitamento quase total das definições de passos e permitindo também o uso de Selenium nativo nos casos onde não existe paralelo na API do Webrat.

Esse tutorial foi testado especificamente no Ubuntu Linux 9.10 e é provável que funcione em ambientes diferentes com pouca ou nenhuma alteração. As gems utilizadas e suas respectivas versões foram:

rails = 2.3.5
cucumber = 0.6.2
cucumber-rails = 0.2.4
database_cleaner = 0.4.3
webrat = 0.6.0
selenium-client = 1.2.17

Estrutura de diretórios

No projeto rails execute script/generate cucumber e altere a estrutura gerada para a seguinte:

- features/  ( Aqui ficam as features que podem ser executadas com o Webrat )
  - js_dependent/ ( Aqui vão as features que exigem o Selenium )
  - support/
    - env.rb ( Configurações comuns à todos )
    - selenium.rb ( Configurações específicas para o Selenium )
    - webrat.rb ( Configurações específicas para o Webrat )
    - paths.rb
  - step_definitions/ ( Definições comuns a todos os modos )
    - webrat/ ( Definições de passos que só funcionam em modo Webrat )
    - selenium/ ( Definições de passos que só funcionam em modo Selenium )
 

Configurações de ambiente

Conforme a estrutura de diretórios definida, no arquivo features/support/env.rb temos as configurações comuns a todos os perfis de execução, no meu caso aqui fica as configurações para factory_girl e matchers do rspec, se não usar nenhum dos dois remova as referências aos mesmos.

No arquivo features/support/selenium.rb configuramos o webrat em modo selenium, desabilitamos o uso de transactional fixtures e definimos a estratégia de limpeza do banco.

No arquivo features/support/webrat.rb apenas configuramos webrat em modo rails.

Perfis de execução

Criaremos 4 perfis de execução para o Cucumber a saber:

• default: Execução de todas as features não marcadas com a tag @wip utilizando o Webrat em modo rails
• wip: Execução das features marcadas com a tag @wip utilizando o Webrat em modo Rails
• selenium: Execução de todas as features não marcadas com a tag @wip utilizando o Webrat em modo Selenium
• selenium_wip: Execução de features marcadas com a tag @wip utilizando o Webrat em modo Selenium

A tag @wip(work in progress) serve para sinalizar cenários em que estamos trabalhando no momento.

Utilizaremos também um recurso interessante das últimas versões do Cucumber para sinalizar os cenários que estão falhando na execução de forma a executar somente estes da próxima vez.

Na execução do Cucumber utilizaremos o formato progress(mais limpo) por padrão, mas quando a execução falhar em algum cenário o formato será mudado para o pretty(mais informativo) de forma a facilitar a leitura.

Para definir os perfis do Cucumber crie o arquivo cucumber.yml na raiz da aplicação.

Tarefas Rake

Como mudamos os perfis de execução padrões, as tarefas rake geradas pelo Cucumber (quando você digitou script/generate cucumber) não são mais compatíveis.  É necessário alterar o arquivo lib/tasks/cucumber.rake para refletir os perfis atuais.

Para ver as tarefas agora disponíveis digite: rake -T cucumber

A vantagem da execução através das tarefas rake ao invés da execução direta (cucumber -p nome_do_perfil) é que a tarefa rake realiza a preparação do banco de teste (rake db:test:prepare) antes de cada execução.

Conclusões

Você pode me perguntar: por que não uso o Cucumber apenas em modo Selenium já que o Webrat possui a limitação quanto ao Javascript?

Baterias de testes de aceitação com Selenium demoram muito mais para executar. Da forma como foi mostrado podemos aproveitar o melhor dos dois mundos: a velocidade e praticidade do Webrat e toda a abrangência do Selenium quando ela for necessária.