/* CODIFICANDO */

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!

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

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á!

É 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

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á!

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.

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.

Você já tentou usar o Rspec para testar se o timestamp gravado em um campo datetime é igual a uma determinada data/horário? O código abaixo possivelmente irá falhar miseravelmente:

@blabla.update_attributes(:foo => "bar)
@blabla.updated_at.should == Time.now

o Time.now é bem preciso e vai pegar várias casas na faixa dos milissegundos, e isso pode gerar alguma diferença entre o retorno de Time.now quando a coluna foi atualizada no banco e quando você realiza a asserção no teste. Uma solução para o problema é fazer:

@blabla.updated_at.should be_close(Time.now, 1.second)

Esse teste passará para qualquer timestamp com uma diferença de +- 1 segundo em relação ao retorno do Time.now no momento da asserção. Altere esse delta T como desejar :).

Essa solução também é indicada para testar valores numéricos de ponto flutuante.

Dei uma atualizada no booleanize e agora ele aceita configuração global. O que isso quer dizer? Significa que se você usa quase sempre as mesmas strings para true ou false, não vai mais precisar ficar duplicando o código em todos os models. Basta adicionar algo como isso no seu environment.rb:

Booleanize::Config.default_strings :true => "Yes", :false => "No"

Assim, toda vez que você usar booleanize :some_boolean_attr nos seus models, não será precisa especificar quais strings deverão ser usadas. Mas se em um caso específico você precisar usar outras strings, basta declarar da forma usual, pois configurações locais têm maior precedência que as globais.

É possível inclusive utilizar o booleanize com internacionalização. Coloque algo como isso no seu arquivo locale/blabla.yml

booleanize:
  true_string: Sim
  false_string: Não

E no seu environment.rb:

Booleanize::Config.default_strings :true => I18n.t("booleanize.true_string"), :false => I18n.t("booleanize.false_string")

E agora é possível instalar o booleanize como um plugin ou como uma gem (créditos para o José Valim). Basta fazer: sudo gem install cassiomarques-booleanize

Continuando a série de posts sobre testes, neste artigo será mostrada uma técnica para simular o retorno das requisições HTTP realizadas durante o processo de autenticação por Oauth. Será utilizado como exemplo uma autenticação ao Twitter, mas a técnica é a mesma para qualquer esquema de autenticação que utilize Oauth.

O que é Oauth?

Se você ainda não sabe o que é o Oauth, dê uma olhada aqui. De forma resumida, o Oauth é um modelo de autenticação que pode ser utilizado quando uma aplicação A (consumer) precisa acessar dados de seus usuários em uma aplicação B (provider). Um exemplo que vem se tornando bem conhecido nos últimos tempos é a autenticação de aplicações que acessam o Twitter para ler e alterar dados de seus usuários. O fluxo é mais ou menos assim:

• A aplicação A deve ser registrada na aplicação B. Ao final desse processo, será gerado um token e um secret, que serão utilizados para a criação de um consumer na aplicação A. A criação deste consumer é feita através deste par token/secret e da URL para a aplicação B.
• Na aplicação A, quando quisermos autenticar um usuário na aplicação B, criamos um request token, a partir do consumer do passo anterior. Este request token também possui um par token/secret, que deve ser guardado de alguma forma. Em aplicações web ele geralmente é guardado na sessão do usuário.
• O request token fornece também uma URL para autorização, para a qual o usuário da aplicação A deverá ser redirecionado. Essa URL pode também receber como argumento (é um request GET) uma URL de callback para alguma área da aplicação A ṕara o qual o usuário será retornado após ter se autenticado com sucesso na aplicação B.
• Ao ser enviado para a aplicação B, o usuário informa seus dados de autenticação e, se estes estiverem corretos, é enviado de volta para a aplicação A. Ao retornar o usuário, a aplicação B também devolve o par token/secret previamente enviado.
• Na aplicação A, o par token/secret recebido é comparado com os dados armazenados previamente na sessão do usuário. Se estes forem iguais, significa que o usuário foi corretamente autenticado na aplicação B. Isso também pode ser mecanismo de segurança.
• Com o par token/secret recebidos, pode-se criar um novo request token e, a partir deste, conseguimos gerar um access token. Com o access token é possível realizar chamadas diretas à API da aplicação B, lendo e alterando dados ali armazenados para o usuário recém autenticado.

Porque testar isso é difícil

O problema em realizar testes funcionais em um processo de autenticação como esse é que o fluxo de execução não fica contido somente na nossa aplicação. Uma vez que o usuário é redirecionado para a aplicação provider, perdemos o controle do que está sendo executado. Considerando-se que precisamos recuperar o fluxo de execução quando o usuário for redirecionado de volta para nossa aplicação, pode-se ter idéia do tamanho do problema.

oauth-test

Além disso, se nossos testes forem fortemente acoplados à aplicação provider e realmente percorrerem o ciclo completo para a autenticação, alguns problemas poderão ocorrer:

• Nossos testes serão lentos.
• Não será possível testar caso a aplicação provider esteja indisponível.

O que precisamos fazer é enganar nossa aplicação. Precisamos fazer com que ela acredite estar enviando requisições para a aplicação provider, sem que isso aconteça de verdade. A primeira idéia que vem à mente é:

Se podemos usar o Rspec junto ao Cucumber, vamos criar mocks e stubs para simular os requests!

Hum… péssima idéia meu amigo. O motivo é simples:

Testes funcionais devem realmente testar sua aplicação. De ponta a ponta. Se você usar mocks e stubs, isso não será muito verdade… O propósito de ferramentas como o Cucumber é testar as coisas como elas realmente são.

Chegamos então a um paradoxo: Não podemos usar mocks e stubs, mas também não temos como testar se nossa aplicação realizar requests reais ao provider. A solução é uma gem muito interessante chamada FakeWeb.

FakeWeb

De forma resumida, o que o FakeWeb faz é acabar com o Net::HTTP. Destruir tudo o que ele faz, matar sua capacidade de realizar requests. Para quem não sabe, toda vez que fazemos um request HTTP a partir de nossa aplicação Rails, quem cuida de tudo é o Net::HTTP.

Como a coisa vai funcionar então? O FakeWeb permite registrar URLS e respectivos retornos. Todo o request feito pelo Net::HTTP será interceptado e a resposta “falsa” será retornada. Nossa aplicação nunca saberá a verdade!

Como saber o que retornar a partir dos requests registrados com o FakeWeb?

Boa pergunta! E a resposta é bastante interessante! Na verdade eu não inventei isso, me baseei no que li no blog Technical Pickles, e funciona muito bem!

Tudo o que temos a fazer é usar o curl e realizar um request a cada URL que nossa aplicação normalmente tentaria acessar durante o processo que pretendemos testar, direcionando a saída para um arquivo.

curl -is http://some.url > output-file

Com essa técnica podemos fazer com que o FakeWeb retorne o conteúdo deste arquivo quando for realizado um request para a URL registrada:

FakeWeb.register_uri('http://some.url', :response => File.join('path', 'to', 'output-file'))

Caso você não saiba exatamente quais são as URLs que deverão ser registradas, o FakeWeb possui uma configuração que faz com que qualquer request a uma URL não registrada (e que acessaria a rede) gere uma exceção contendo a URL solicitada. É uma forma suja de descobrir as URLs, mas resolveu meu problema :)

FakeWeb.allow_net_connect = false

Aplicando isso para testar o processo de autenticação ao Twitter com OAuth

Precisamos criar o código capaz de executar o seguinte step:

Given I am logged in

Estou considerando como exemplo a utilização da gem twitter-auth, a qual fornece mecanismos para autenticação ao Twitter usando OAuth ou autenticação básica.

No arquivo features/support/env.rb registramos as URLs no FakeWeb, para as quais já temos os retornos esperados dentro de arquivo gerados com o auxílio do curl:

require 'fake_web'
FakeWeb.allow_net_connect = false
FakeWeb.register_uri(:post, 'https://twitter.com:443/oauth/request_token', :string => 'oauth_token=faketoken&oauth_token_secret=faketokensecret')
FakeWeb.register_uri(:post, 'https://twitter.com:443/oauth/access_token', :string => 'oauth_token=fakeaccesstoken&oauth_token_secret=fakeaccesstokensecret')
FakeWeb.register_uri(:get, 'https://twitter.com:443/account/verify_credentials.json', :response => File.join(RAILS_ROOT, 'features', 'fixtures', 'credentials.json'))

Além disso, precisamos simular o redirecionamento realizado pelo provider de volta à nossa aplicação. Tomando como exemplo o código do controller utilizado no twitter-auth para criar as sessões:

class SessionsController < ApplicationController
  def new
    if TwitterAuth.oauth?
      @request_token = TwitterAuth.consumer.get_request_token
      session[:request_token] = @request_token.token
      session[:request_token_secret] = @request_token.secret

      url = @request_token.authorize_url
      url << "&oauth_callback=#{CGI.escape(TwitterAuth.oauth_callback)}" if TwitterAuth.oauth_callback?
      redirect_to url
    else
      # we don't have to do anything, it's just a simple form for HTTP basic!
    end
  end

  def oauth_callback
    unless session[:request_token] && session[:request_token_secret]
      authentication_failed('No authentication information was found in the session. Please try again.') and return
    end

   unless params[:oauth_token].blank? || session[:request_token] ==  params[:oauth_token]
     authentication_failed('Authentication information does not match session information. Please try again.') and return
   end

   @request_token = OAuth::RequestToken.new(TwitterAuth.consumer, session[:request_token], session[:request_token_secret])

   @access_token = @request_token.get_access_token

   #...

pode-se perceber que a primeira action acessada é new, a qual redireciona o usuário para realizar autenticação no Twitter. Quando o usuário é autenticado, ele é redirecionado de volta para a action oauth_callback do controlle SessionsController. Na action new são colocados na sessão o par token/secret de request, os quais serão confirmados quando o usuário voltar para a action oauth_callback. Será necessário realizar dois requests distintos na implementação do nosso step: um para colocar os dados na sessão e um segundo para simular o redirecionamento para a action oauth_callback.

O implementação do step ficaria mais ou menos assim:

Given /^I am logged in$/ do
  visit login_url
  visit oauth_callback_url
end

Tudo isso pra que duas linhas de código funcionem como esperado!