Para nossa “sorte” o Cake já tem algumas facilidades para implementação de testes no estilo xUnit, usando o framework SimpleTest, que é uma mistura de JUnit com JWebUnit permitindo tanto a implementação de testes de unidade/integração como testes funcionais/aceitação simulando comportando do Browser.

O código-fonte produzido está disponível no GitHub, e em breve vamos escrever alguns artigos explicando melhor como foi a experiência. Mas, como sempre, feedbacks já são muito bem vindos!

Fica algumas boas referências de sites e blogs sobre o assunto:

• KISS: blog muito movimentado sobre TDD em CakePHP, em PT-BR!
• Debuggable: empresa especializada em desenvolvimento em CakePHP, acredito que alguns componentes de teste foram desenvolvidos por eles.
• Mark Story: blog dedicado a CakePHP e assuntos relacionados.
• Testes automatizados no CakePHP: excelente apresentação sobre TDD em CakePHP.

Com o SVN, enviaria pra ele um .zip do meu projeto, mas como estamos usando um DCVS podemos fazer isso com os recursos do Git. Primeiramente, devo rodar um processo na minha máquina que permitirá outra pessoa dentro da mesma rede acessar meu repositório usando o protocolo git. Existem outras opções para compartilhar repositórios, veja aqui mais detalhes. Para iniciar o git-daemon usei o comando abaixo:

git daemon --verbose --export-all --enable=upload-pack --enable=receive-pack --base-path=/Users/sauloarruda/Projetos/Users/sauloarruda/Projetos/sauloarruda.eti.br/libres/libres-php/.git

E o outro desenvolvedor simplesmente usou o comando abaixo para clonar meu repositório. O legal nesse caso é que ele consegue pegar minhas atualizações com git pull, mas quando ele faz um commit as mudanças não são feitas no meu repositório.

git clone git://172.20.12.180/sauloarruda.eti.br/libres/libres-php/.git

Referências:

• Using Git Daemon to share your Git repository
• Git Magic – Cloning Around
• Stack Overflow – How can I make my local repository available for git-pull?

Nesse exemplo, o campo Authors permite que conforme você vá digitando, ele abre sugestões de autores já cadastrados no banco de dados. Permite também que você separe vários autores por vírgula e cadastra os autores que não existem ainda no banco de dados.

A implementação do controller nesse caso, usa o componente Autocomplete.Local do Script.aculo.us que não é muito complicado de ser usado e inclusive já vem de brinde com o Rails. Se você quer saber mais detalhes sobre isso, dá uma olhada no arquivo app/views/books/_authors.html.erb.  O que vejo ser mais complicado nesse exemplo é a implementação do model Book que deve ter uma lista de autores.

Neste momento você deve estar se perguntando: Mas não tem nada complicado nisso! Eu simplesmente vou receber um parâmetro param[:book][:authors_s] e chamar o método split(",") para obter um array de nomes de autores e chamar o método Author.find_or_create_by_name(author_name) para criá-lo.

E eu respondo: Exatamente! Sua solução está perfeita. Mas tenho uma pequena pergunta: Onde esse código será colocado? [  ] Na classe books_controller no método create. [  ] Na classe book.

Tendenciosa minha pergunta, não? Se você pensar um pouco e lembrar das palestras sobre MVC na hora você responde “Na classe book”. Mas o primeiro instinto é implementar no controller, inclusive já vi centenas de códigos em Rails cometendo exatamente esse erro. Lógica de negócio deve ficar em objeto de negócio (ou de domínio se você preferir) e não no controller.

Logo, no nosso caso, o código da classe Book ficaria algo parecido com isso (repare que o campo Tags, logo abaixo do campo Authors, tem o mesmo comportamento):

O objetivo do código acima é permitir que um objeto da classe Book seja instanciado no controller desta forma:

Vamos dissecar um pouco mais o código:

• Na view, fazemos um bind para o atributo book.authors_s, que é uma representação string do objeto authors criada por nós: <%= f.text_field :authors_s %>. Logo, o parâmetro params[:book][:authors_s] no exemplo seria "Kent Beck, Martin Fowler".
• Declarar o atributo authors com o comando: has_and_belongs_to_many :authors, :join_table => "books_authors" permite que a classe receba um array de objetos da classe Author como o parâmetro :authors. Logo, temos que converter o atributo authors_s para o atributo authors, lembrando da necessidade de gravar os autores novos no banco de dados.
• Para resolver esse problema, implementei alguns callbacks:
• O primeiro no método before_save que faz o algoritmo que falamos anteriormente (split + find_or_create_by_name). Desta forma, os autores novos só serão gravados caso o objeto book seja válido (before_save só é chamado após a validação).
• O segundo no método after_find que carrega o atributo authors_s com os valores do atributo author. Desta forma, permite a edição de livros.

Naturalmente é possível fazer algumas melhorias no código, mas a idéia que gostaria de apresentar é essa. Sinta-se à vontade para baixar o código completo no githut e deixar seus comentários/dúvidas/sugestões/críticas abaixo.

Updated 25/02: Meu amigo e co-worker Rodrigo Toledo me deu várias dicas sobre como este exemplo pode ser implementado, inclusive resolvendo alguns bugs que ficaram pra trás. Resumo das alterações:

• Retiramos o controller “autocomplete_controller” incluindo a lógica no helper e simplesmente imprimindo um json na view para auto completar os campos tags e authors.
• Alteramos a lógica do model book.rb para usar os callbacks after_find e before_save para fazer o bind da string separada por vírgulas para um array.
• Pequena alteração para não usar eval no método Book.array_to_string conforme o comentário.

Todo o código já está comitado no github e já fiz as alterações nos pasties mostrados no artigo.

Quando rodo os testes usando o comando “cucumber” recebia a seguinte warning:

!!!!! DEPRECATION NOTICE !!!!!
The WWW constant is deprecated, please switch to the new top-level Mechanize
constant. WWW will be removed in Mechanize version 2.0

You've referenced the WWW constant from /opt/local/lib/ruby/gems/1.8/gems/webrat-0.7.0/lib/webrat/adapters/mechanize.rb:43:in `mechanize', please
switch the "WWW" to "Mechanize". Thanks!

Sincerely,

Pew Pew Pew

Consultando o changelog do Mechanize, a versão 1.0.0 deprecia o uso do módulo WWW, que ainda não foi atualizado no Webrat. Para resolver o problema basta instalar a versão anterior do Mechanize (0.9.0) usando o comando:

sudo gem install mechanize --version '= 0.9.0'

E dizendo no arquivo env.rb para usar a versão 0.9.0 conforme abaixo:

require 'rubygems'
gem 'mechanize', '= 0.9.0'


• http://miud.in/1zU: Série de artigos sobre Cucumber. Muito bem elaborado!
• http://miud.in/1zS: Artigo introdutório do Urubatan.
• http://miud.in/1zR: Introdução sobre Cucumber para testes funcionais (usando o webrat).
• http://miud.in/1zQ: Site oficial, tem vários exemplos mas a documentação não é bem organizada.
• http://miud.in/1zP: Como integrar o Cucumber com o Selenium.
• http://miud.in/1zT: Livro – The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends – tem vários capítulos sobre Cucumber
• http://miud.in/1Kc: Artigo bastante simples que usa Webrat para testar aplicação PHP.

O foco deste, é apresentar minha experiência em usar o Cucumber integrado com o Selenium e mostrar um exemplo de como é simples implementar testes funcionais. Para começar, leia essa documentação que explica como configurar seu ambiente. Se você usa MacOS Snow Leopard (10.5) deve passar pelos mesmos problemas que eu tive e que encontrei a solução neste link.

A idéia central é escrever estórias para teste de telas (caixa preta). Disponibilizei no github o código-fonte da aplicação em Rails que está sendo testada e de outra aplicação, somente Ruby, usando Cucumber + Selenium. Para demonstrar o uso do Selenium, escolhi um cenário bastante simples, trata-se de um história de autenticação de usuários:

Perceba que nos preocupamos em escrever a história o mais “User Friendly” possível. Isso facilita bastante o entendimento sobre o que você está de fato testando e o que o seu usuário (ou cliente) acha que você deveria testar. E, como você já deve saber, as palavras-chave “dado”, “quando” e “então” representam ações que são implementadas em Ruby. Para começar, configuramos no arquivo support/env.rb o ambiente da API para Selenium em Ruby criando uma instância da classe Selenium::SeleniumDriver. 

No arquivo support/paths.rb configuramos o mapeamento de nome de páginas para URIs e também de label de campos para o nome do campo no formulário HTML. Os métodos path_to, field_for e button_for fazem essas funções.

OK, concordo com vocês que essas funções não fazem lá muita coisa, mas lembre-se que estamos fazendo o nosso primeiro caso de teste, tenha certeza que serão úteis no futuro próximo. Um exemplo que eu já posso citar foram os testes que implementamos para testar uma aplicação, na verdade um portal, desenvolvido em Drupal, onde o “label” dos campos não era nem um pouco parecido com o nome (do componente HTML) do campo. Lembrando que as histórias tem de ficar o mais próximo possível da taxonomia (ou idioma) do seu usuário.

Agora, vamos à parte que interessa, de fato a implementação dos passos descritos nas estórias. Criei o arquivo step_definitions/common_steps.rb contendo os passos mais comuns que você deverá usar na maioria de suas estórias. Para passos específicos de determinada história, recomenda-se criar um outro arquivo no diretório step_definitions com o nome da estória.

O exemplo é bastante simples, e a aplicação Rails do github contém uma implementação bastante simples do que está sendo testado. Para executar, basta usar o comando “cucumber” na raiz do projeto de testes. Lembrando que você deve iniciar o servidor do Selenium usando o comando “selenium” (isso funcionou pra mim após instalar o Selenium RC).

Se você tiver dúvidas ou problemas na execução do exemplo, fique à vontade de postar nos comentários que farei o possível para tentar ajudar. E, por hora ficamos por aqui. Em breve devo postar alguns exemplos de passos mais complexos como uso de tabelas e/ou editores ricos. Estamos trabalhando nisso agora!

O princípio básico da técnica é dedicar 25 minutos de puro trabalho com 5 minutos de descanso. Isso é o que se chama 1 (um) “Pomodoro”. Após 4 Pomodoros você faz uma pausa maior. A apresentação que usei para apresentar a técnica aqui na Agence está disponível no slideshare. Além disso, tem um livro gratuito escrito pelo autor da técnica, Francesco Cirillo.

Nossa experiência até o momento tem sido bastante produtiva. Estamos usando fichas pautadas 4” x 6” para registrar diariamente e no fim da semana o estagiário lança as atividades em um sistema que ele mesmo fez. Estamos trabalhando em alguns relatórios para avaliar, principalmente, a constância da equipe. Provavelmente usaremos um gráfico de controle pra isso.

Por enquanto é isso que temos a dizer. Assim que as coisas começarem a fazer mais sentido pra gente, vou postando aqui as experiências.

Após a palestra participei de uma mesa redonda com os professores Karen, Alfredo e Jane para discussão de temas relacionado a tecnologia e como os alunos podem escolher suas especialidades após formados e entrar no mercado de trabalho.

Parabéns ao pessoal da organização e bom restante de semana de sistemas da informação para os alunos!

Updated in 18/11: Fotos disponíveis em http://www.cpcx.ufms.br/semanasi2009/?page_id=120.

PS: Coloquei os slides no SlideShare abaixo para consultas aos links, downloads, etc.