Criando example groups personalizados no Rspec

Quem usa o Rspec com o Rails sabe que existem alguns tipos de specs pré-definidos. Estes tipos de spec são chamados de ‘example groups’ e no Rails são associados aos tipos de classe que visam testar. Temos então o ‘models example group’, o ‘controller example group’, etc. Para cada grupo, o Rspec (e mais precisamente o rspec-rails) cuida de incluir alguns helpers específicos, além de dar ao desenvolvedor a change de incluir seus próprios helpers e macros, criar hooks para executar código antes ou depois da execução de cada exemplo, etc. Tudo isso de forma controlada, para tipos de specs específicos.

Por exemplo, se você escreveu um conjunto de macros e helpers para as specs dos seus models, você poderia simplesmente colocar todo mundo em um arquivo e fazer um require disso no seu spec_helper.rb. O problema disso é que, além de feio e bagunçado, estes helpers e macros de model ficariam também disponíveis para as specs de controllers, views, helpers, etc. Então para organizar as coisas, podemos alterar nosso spec_helper.rb e adicionar o seguinte no bloco do método Spec::Runner.configure:

require 'spec/my_cool_model_macros'

Spec::Runner.configure do |config|
  config.include(MyCoolModelMacros, :type => :model)
end

e todas as macros definidas no seu module MyCoolModelMacros estariam disponíveis nas suas specs, mas somente para models!

Além de poder incluir novos modules de forma contralada, também é possível usar este recurso para executar código antes ou depois de cada exemplo, mas somente para exemplos que façam parte de um example group específico:

Spec::Runner.configure do |config|
  config.before(:each, :behaviour_type => :controller) do
    # ...
  end
end

Isso executará o código dentro do bloco config.before antes de cada exemplo executado, mas somente nas suas specs de controllers.

Legal, isso já me dá bastante controle e flexibilidade. Mas e se eu quiser criar meus próprios example groups? Considere o meu caso por exemplo: Eu tenho uma aplicação Rails com um banco próprio mas que também precisa acessar uma base legada. Para rodar os testes, eu tenho uma cópia dessa base legada, mas só com a estrutura, sem dados. Exatamente como ocorre com a base de dados de teste padrão do Rails. A cada novo exemplo, preciso limpar todos os dados criados nessa base legada de teste para poder preparar o próximo cenário. É óbvio que seria perda de tempo ficar limpando essa base legada para todos os exemplos, mesmo aqueles que não tem relação alguma com as partes do código que acessam este outro banco. Para isso, podemos criar um exemple group específico e limitar a funcionalidade.

Como dito anteriormente, o rspec-rails já possui alguns example groups pré-definidos. O problema de criar um exemple group totalmente novo é que se a sua spec for referente a um model, você não terá acesso a todos aqueles helpers e macros bacanas que existem em uma spec de model normal dentro de sua aplicação Rails. Por isso, ao invés de criar do zero, vamos aproveitar o que o rspec-rails já fornece.

Normalmente, para criar um novo example group basta criarmos uma nova classe que herde de Spec::Example::ExampleGroup (na verdade isso já acontece por baixo dos panos toda vez que você cria um bloco describe()) e dentro dessa classe registrar o nosso novo tipo. Algo mais ou menos assim:

class MyCustomExampleGroup < Spec::Example::ExampleGroup
  Spec::Example::ExampleGroupFactory.register(:foobar, self)
end

Com isso ganhamos um novo example group :foobar e podemos associar nossas specs ao mesmo. Uma vez feito isso, fica fácil configurarmos o Rspec para executar código de forma restrita às specs que pertencem a este grupo, como descrito acima.

O rspec-rails fornece alguns example groups a partir dos quais podemos derivar nossas próprias classes.

• Spec::Rails::Example::ModelExampleGroup para models
• Spec::Rails::Example::ControllerExampleGroup para controllers
• Spec::Rails::Example::HelperExampleGroup para helpers
• Spec::Rails::Example::ViewExampleGroup para views

Para não perder nenhuma das facilidades do rspec-rails, vamos herdar desses example groups, ao invés de herdar do ExampleGroup padrão do Rspec.

class MyCrazyModelExampleGroup < Spec::Rails::Example::ModelExampleGroup
  Spec::Example::ExampleGroupFactory.register(:crazy_stuff, self)
end

Já temos nosso example group e já sabemos como específicar configurações para nossas specs que valem somente para testes dos models. Mas e como definir quais specs farão parte do grupo :crazy_stuff? Simples:

describe MyModel, :type => :crazy_stuff do
  #...
end

Blocos com argumentos opcionais no Ruby 1.8.x

O Ruby 1.9 tem umas coisas novas bem legais. Uma delas é a habilidade de definir valores padrão para os argumentos passados para um bloco de código, como no exemplo abaixo:

pow = proc { |a, b = 2| a**b }

pow.call 3, 3
# 27

pow.call 3
# 9

Isso é bem útil, por exemplo, quando criamos um método dinâmicamente com metaprogramação e queremos que algum argumento desse método seja opcional.

class MyMath
  class << self
    define_method :pow do |base, exponent = 2|
      base**exponent
    end
  end
end

MyMath.pow 3 # 9
MyMath.pow 2, 3 # 8

Mas no Ruby 1.8.x não temos isso, não podemos definir valores padrão para os argumentos de um bloco. Ok, sua aplicação roda com Ruby 1.8.x e você tem que criar métodos dinâmicamente e estes métodos devem ter parâmetros opcionais. Existe uma solução, não tão elegante quanto como ocorre no Ruby 1.9 mas bastante funcional e simples.

class MyMath
  class << self
    define_method :pow do |*args|
      base, exponent = args[0], args[1] || 2
      base**exponent
    end
  end
end

MyMath.pow 3 # 9
MyMath.pow 2, 3 # 8

Ao passarmos um splat (aquele carinha com um asterisco à esquerda) como argumento para o bloco, o que quer que chegue ali será tratado como um array. Dessa forma, podemos simular a existência de valores padrão para os argumentos. Podemos na verdade passar qualquer quantidade de argumentos e definir os valores padrão conforme desejarmos.

O que se perde, infelizmente, é a capacidade de validar a quantidade de argumentos que o método deve ser receber quando for executado. Mas isso pode ser contornado validando-se os elementos do array recebido pelo bloco.

Eu costumo usar essa técnica para criar métodos que podem ou não receber um hash com opções, o que se mostra útil por exemplo em plugins ou gems, como por exemplo:

module MyModule
  module ClassMethods
    def do_the_magic
      class_eval do
        define_method :magic_method do |*args|
          options = args.first || {}
          # ...
        end
      end
    end
  end

  def self.included(base)
    base.extend ClassMethods
  end
end

class MyClass
  include MyModule
end

obj = MyClass.new
obj.magic_method # funciona
obj.magic_method :abra => "cadabra" # também funciona!

Como criar gems que instalam executáveis na sua máquina

Precisei criar uma gem que gerasse um executável no ambiente, sendo possível assim executar a biblioteca como um utilitário de linha de comando. Encontrei muito pouca documentação sobre como fazer isso, então vou deixar aqui caso seja útil para mais alguém.

O segredo é manter uma pasta bin dentro da estrutura de diretórios da sua gem e colocar ali dentro os arquivos que você deseja que se tornem executáveis após a instalação da gem. Você deve salvar estes arquivos sem a extensão .rb, caso contrário terá que escrever .rb na linha de comando também para inicializar o programa. Em sistemas POSIX você pode criar arquivos executáveis e usar o “shebang” para instruir o shell sobre qual programa deve ser utilizado para executar o conteúdo do arquivo. Assim, basta adicionar a seguinte linha ao início do arquivo:

#! /usr/bin/env ruby

Após criar seu arquivo dentro de bin, basta adicionar o mesmo como um executável à sua gemspec. Estou usando o Jeweler para criar minhas gems, então tudo o que preciso fazer é gerar minha gemspec usando a seguinte raketask que o arquivo será criado corretamente:

rake gemspec

Isso vai criar um arquivo gemspec contendo a seguinte linha:

Gem::Specification.new do |s|
  ...
  s.executables = ["bla", "ble", "bli"]
  ...
end

Onde bla, ble, bli são arquivos dentro de bin que devem se transformar em executáveis após a instalação da gem. Quando sua gem for instalada, estes arquivos será copiados para dentro de /usr/bin e receberão permissão para serem executados.

Palestra sobre Ruby on Rails na FAPI

Nesta quarta-feira dia 28/10/09, às 19:30h vou falar um pouco sobre Ruby on Rails na Faculdade de Pindamonhanga, durante a Jornada Acadêmica de Sistemas de Informação.
No ano passado apresentei um mini-curso sobre Ruby lá e foi bem bacana, espero me divertir e poder apresentar um pouco do Rails aos alunos, professores e outras pessoas interessadas.

Se você mora no Vale do Paraíba ou perto e quer ouvir um pouco sobre Rails, não deixe de ir!

Economize tempo e mantenha o foco ao rodar seus testes

Testar é bom. Esperar os testes rodarem, não. Quando um teste específico falha, o ideal é rodar apenas esse teste e não toda a suíte de testes novamente. Depois que esse cara estiver passando, ai sim rodamos tudo, para termos certeza de que nada mais quebrou. Além disso, se você estiver escrevendo testes para uma app Rails, sabe que sempre que você faz rake spec todo o seu banco é recarregado. Ok, legal… mas e se você quiser rodar apenas um arquivo de specs onde tudo é feito com mocks/stubs e não há acesso ao banco? Porque esperar todo o banco ser carregado?

Seguem abaixo algumas dicas para agilizar a execução dos seus testes.

Para o Rspec

Rodar apenas um arquivo (carregando o banco de teste):

rake spec SPEC=[caminho para o arquivo]_spec.rb

Rodar apenas um arquivo (sem carregar o banco, útil por exemplo para rodar specs de controllers/helpers quando utiliza-se mocks/stubs)

spec [caminho para o arquivo]_spec.rb

Rodar apenas um teste específico dentro do seu arquivo (10 é o número da linha onde se encontra o bloco ‘it’ que você quer executar. Funciona de forma idêntica caso você use o comando ’spec’ ao invés de ‘rake’)

rake spec SPEC=[caminho para o arquivo]_spec.rb:10

Para o Cucumber

Rodar apenas um arquivo

rake features FEATURE=features/[seu arquivo].feeature

Rodar apenas um cenário (10 é a linha onde começa a declaração do cenário)

rake features FEATURE=features/[seu arquivo].feature:10

6o Encontro do Guru-SP – Mesa redonda sobre testes automatizados

Neste sábado, dia 26 de setembro, vai rolar o 6o encontro do Guru-SP, o Grupo de Usuários Ruby de São Paulo. O evento vai acontecer no auditório do prédio da GoNow. Tive o prazer de ser convidado para participar da mesa como debatedor, espero não fazer muito feio no meio de todos os feras que estarão participando comigo :)

Vamos fazer um debate sobre diversos tópicos relacionados a utilização de testes automatizados, TDD, BDD e tudo mais. Acho que será uma ótima oportunidade para aprender e mostrar as diversas vantagens que da utilização de testes.

Mais informações no rubyinside.com.br e no site do Guru-SP.

Vejo vocês por lá!

Dica rápida: Testando igualdade entre arrays de models

É comum testarmos métodos que retornam arrays de models. Um bom exemplo disso é quando testamos named_scopes (eu gosto de testar named_scopes pra valer, batendo no banco e não somente usando macros como as do Remarkable). A grande pagadinha é que a ordem na qual os objetos serão retornados do banco é totalmente imprevisível, a não ser que seu método já traga os itens ordenados por padrão. Assim, testes como o exemplo abaixo podem hora passar, hora não:

describe ".active" do
  before :each do
    @user1 = User.make :active => true
    @user2 = User.make :active => false
    @user3 = User.make :active => true
    @user4 = User.make :active => false
  end

  it "retorna somente usuários ativos" do
    User.active.should == [@user1, @user4]
  end
end

Uma maneira segura de testar isso é usar a classe Set, da biblioteca padrão do Ruby. Um Set representa um conjunto matemático, sendo que a igualdade entre dois conjuntos existe quando ambos os conjuntos possuem exatamente os mesmos elementos, independentemente da ordenação. Assim, podemos reescrever a linha da spec que faz a asserção e termos certeza de que ele terá sempre o mesmo comportamento:

User.active.to_set.should == Set.new([@user1, @user4])

Rails Summit 2009

Rails Summit

Ok, acho que a maioria das pessoas que costuma ler o blog já deve estar sabendo que este ano teremos mais uma edição do Rails Summit. Para quem não conhece, esse é maior evento da América Latina sobre Rails. Ano passado eu fui e posso dizer que foi um evento excelente.
Inicialmente eu não ia escrever nada específico sobre o evento aqui, mas estão sorteando dois ingressos este ano e tudo o que eu precisei fazer para concorrer foi: a) Seguir o @railssmummit no Twitter, o que eu já fazia e b) Escrever este post.

Seria legal se eu ganhasse um desses ingressos e pudesse economizar 400 mangos :)

Para quem for, vejo vocês por lá!

Testando sweepers com Rspec

O problema

Quando usamos caching no Rails, precisamos criar também algum mecanismo para expirar esses caches quando os mesmos não forem mais válidos. Geralmente um cache não é mais válido quando o recurso exibido teve seu estado alterado na aplicação. Por exemplo: Você tem um blog e usa caching para não ter que ir ao banco toda vez que os posts forem exibidos. Entretanto, se um post for atualizado, seu respectivo cache deve ser expirado, caso contrário as alterações nunca serão visualizadas.

Um mecanismo bastante utilizado para expirar caches são os sweepers. Sweepers são objetos compartilhados, muito semelhantes aos observers do ActiveRecord (na verdade um Sweeper é uma subclasse de Observer), que podem ser registrados nos controllers de forma semelhante a filtros, para observar alterações em models e expirar os respectivos caches.

O problema que eu tive foi que queria testar um sweeper com meu querido Rspec. Mais especificamente, um sweeper que expirava um fragment cache, que é um cache para apenas um pedaço da minha página. Não achei nada pronto pra isso, nenhuma facilidade. Resolvi coçar minha própria coceira e criar alguma coisa que pudesse me ajudar.

Não vou explicar aqui como funciona caching no Rails, nem como usar Sweepers. Você pode pesquisar mais sobre isso aqui.

Vamos seguir utilizando o velho e muito mais que manjado exemplo da Blog App. Vamos considerar que a página inicial da nossa app possui uma área com os posts mais recentes, sobre a qual foi aplicado fragment caching. Para expirar este cache, poderiamos ter um sweeper mais ou menos assim:

class PostSweeper < ActionController::Caching::Sweeper
  observe Post

  def expire_post(post)
    expire_fragment "post_#{post.id}"
  end

  alias_method :after_save, :expire_post
  alias_method :after_destroy, :expire_post
end

Como testar isso? Como saber que o fragmento correto é expirado quando alteramos o registro no banco?

A solução

Para testar esse sweeper, criei um controller “de teste”, sem utilidade para a aplicação. Porque eu não usei um controller já existente? Porque eu não queria criar dependência entre os testes. Não gosto da idéia de ter que depender de uma classe diferente da que está sendo testada para que meu teste passe, pelo menos não se eu puder evitar.
Usei um nome diferente de PostsController, para não redefinir a classe durante os testes, isso poderia causar problemas. O código abaixo pode ser definido no próprio arquivo da spec, logo acima do seu bloco describe principal, por exemplo.

class FooBarsController < ApplicationController
  cache_sweeper :post_sweeper

  def update
    @post = Post.find(params[:id])
    @post.update_attributes :contents, "hello world!"
  end

  def destroy
    @post = Post.find(params[:id])
    @post.destroy
  end
end

describe PostSweeper do
  #...
end

O próximo passo é criar uma forma de habilitar o caching em nossos testes. Por padrão ele fica desabilitado no ambiente de teste, para tornar tudo mais rápido. Vamos ter que habilitá-lo se quisermos que nosso teste funcione. Aqui habilito o caching somente para a spec em questão, sem alterar o comportamento para os demais testes da nossa aplicação. Para isso, criei um helper:

def performing_cache
  ActionController::Base.perform_caching = true
  yield
  ActionController::Base.perform_caching = false
end

A idéia para o teste é invocar as actions do FooBarsController e ver se o cache é expirado quando o post é atualizado ou removido. Simples né? Hum… depende… como vamos invocar as actions? Como este é uma spec para o sweeper e não para o controller, não podemos simplesmente fazer algo como

  put :update, :id => "1"

como fariamos em um teste de controller. Nossa spec não saberia qual controller é dono da action update em questão. Vamos precisar cavar um pouco e descobrir outra forma:

describe PostSweeper do
  before :all do
    @app = ActionController::Integration::Session.new
    ActionController::Routing::Routes.draw do |map|
      map.resources :foo_bars, :only => [:update, :destroy]
    end
  end

  #...
end

No código acima criamos a variável de instância @app. Ela representa uma app Rails, sobre a qual podemos invocar actions. Criamos também uma rota para nosso controller, de forma a podermos usar URIs para as actions.

Agora precisamos criar um matcher do Rspec para verificar se o fragmento está sendo devidamente expirado. Fiz de forma bem simples, poderia ser melhorado. Basicamente o que faço aqui é verificar se o cache store do controller de teste recebe uma mensagem pedindo para que o fragment cache seja expirado.

Spec::Matchers.define :expire_fragment do |fragment, options|
  match do |controller|
    controller.cache_store.should_receive(:delete).with("views/#{fragment}", options)
  end
end

Ok, precisei dar uma fuçadinha no código do Rails para descobrir como fazer isso :)

Agora juntando tudo, podemos escrever uma spec assim:

describe PostSweeper do
  before :all do
    @app = ActionController::Integration::Session.new
    ActionController::Routing::Routes.draw do |map|
      map.resources :foo_bars, :only => [:update, :destroy]
    end
  end

  before :each do
    @post = Post.create(:contents => "blablabla")
  end

  it "deve limpar o cache quando o post for atualizado" do
    FooBarsController.should expire_fragment("post_#{@post.id}", nil)
    performing_cache do
      @app.put("/foo_bars/#{@post.id}")
    end
  end

  it "deve limpar o cache quando o post for removido" do
    FooBarsController.should expire_fragment("post_#{@post.id}", nil)
    performing_cache do
      @app.delete("/foo_bars/#{@post.id}")
    end
  end
end

Precisamos passar nil como segundo argumento para o matcher, porque ali iriam as opções para expirar o cache, as quais não estamos usando. Preciso pensar em uma forma melhor de fazer isso depois, para passar um segundo argumento somente quando ele for utilizado. Com Ruby 1.9 isso poderia ser resolvido facilmente, pois argumentos de blocos aceitam valores default, como acontece com argumentos de métodos.

Verificando atributos dos elementos da página com Webrat

Algumas vezes você vai precisar verificar os atributos dos elementos html de uma página da sua aplicação com Cucumber + Webrat. Seria uma forma menos problemática de fazer testes de view, ao invés de usar o Rspec para isso (eu definitivamente não testo views com o Rspec e não aconselho ninguém a fazê-lo).

O Webrat é capaz de localizar seus elementos na view das seguintes formas: a partir de seu id, a partir do valor de atributo name, por uma string xpath ou pelo label que indica o elemento na página. Eu gosto bastante de usar a última opção, pois torna os testes mais legíveis. Quando este elemento é encontrado na página, o Webrat o retornará e então poderemos fazer certas verificações sobre ele, incluindo analisar os valores de seus atributos.

Por exemplo, podemos verificar se um campo de um formulário está desabilitado (ou seja, se o atributo ‘disabled’ está presente)

Then /^the field "([^\"]*)" should be disabled$/ do |label|
  field_labeled(label).element.attribute('disabled').to_s.should == "disabled"
end

O método field_labeled encontra um elemento a partir de seu label. Sobre este elemento podemos verificar o hash attributes, o qual guarda o valor de todos os atributos presentes na tag html em questão.