Uma maneira de conseguir isso é através da gem/plugin rack-debug. Para utilizá-la, segui os passos abaixo.

1. Instalação

 $ script/plugin install git://github.com/ddollar/rack-debug.git
 
 # config/environments/development.rb
 config.middleware.use "Rack::Debug"

2. Chamar o debugger onde necessário:

  def create
    @status = current_user.statuses.create(params[:status])
    debugger
    if @status.valid?
...

3. Conectar-se ao debugger

 # No diretório da aplicação, chamar a task rake
 $ rake debug
 Connected.

4. Ao executar a linha onde o debugger foi chamado, a aplicação para e você tem acesso ao console do debugger

 (rdb:1) p @status
 #<Status id: 231, text: "Testing rack-debug", user_id: 4, ...>

Pronto. Happy debugging!

Update: ao chamar a task rake, pode ocorrer um erro com a mensagem “Server is not running or Passenger has spooled down”. Neste caso, reinicie o Apache e tudo deve funcionar normalmente.

Uma técnica comum é utilizar um mock ou stub na classe Time do Ruby para manipular o horário de acordo com o desejado. Isso vai contra um princípio importante do uso de fake objects em testes: “Não use fakes em objetos que não são seus“. Na maioria do tempo isso pode não causar problemas, mas alterar o comportamento de uma classe usada internamente pela linguagem não soa bem e pode causar bugs difíceis de rastrear.

Aí entra a gem time-warp. Ela ainda trabalha sobre as classes do Ruby, mas provê uma camada específica para testes para todo código executado em um bloco definido pelo programador. Um exemplo de uso (da nossa aplicação feita para o Rails Rumble):

it "should only silence tweets with the desired word inside the configured time interval" do
  pretend_now_is(Time.now.utc.beginning_of_day + 1.hour) do
    tweet1.sent_at = 2.minutes.ago
    tweet2.sent_at = 32.minutes.from_now
    tweet3.sent_at = 1.hour.from_now
 
    collection = [tweet1, tweet2, tweet3]
 
    Silencer.apply(collection, {:word => "soccer", :until => 30.minutes.from_now})
  end
 
  tweet1.should be_filtered
  tweet2.should be_filtered
  tweet3.should_not be_filtered
end

A gem adiciona o método “pretend_now_is”, que recebe um parâmetro com o horário desejado e um bloco. Dentro desse bloco, todo código executado é “transportado no tempo” para o horário definido. Além de tornar a manipulação das classes de tempo mais segura, o código fica muito mais elegante.

Veja mais detalhes no README da gem.

Download.

Obrigado a todos que apareceram por lá! Qualquer feedback é muito bem-vindo.

Um benefício resultante dessa prática é poder executar os testes contra várias versões do Ruby e, assim, verificar alterações em sua estrutura.

Se você usa o TextMate, é muito fácil criar um caso de testes. Basta abrir uma janela do editor, ativar o bundle do Ruby, digitar tc e pressionar a tecla tab:

Com isso temos um “esqueleto” de um caso de testes pronto. Pressionando tab, o foco do cursor passa por pontos importantes, como o require da biblioteca a ser testada, o nome do caso de testes etc. Agora, basta modificar de acordo com o que queremos testar e, através do atalho command+R, executar os testes e verificar o resultado:

Veja também:

Aprendizado orientado por testes

Não existe algo como um “framework BDD”. Tenha em mente que quem pratica ou não o BDD é o desenvolvedor. O que existe são frameworks ou bibliotecas que adicionam uma boa dose de açúcar sintático para facilitar o estilo de escrita para quem deseja praticar essa técnica de testes.

Os maiores proponentes do BDD enfatizam que a maior mudança em relação às técnicas tradicionais é mesmo a sintaxe. Porém, isso não quer dizer que basta utilizar uma sintaxe “mais legível” (o que é discutível também) para pular no vagão do BDD. A sintaxe bonitinha é um auxílio, uma ferramenta com o objetivo de diminuir as dificuldades na transição de um modo de pensar, que é onde a verdadeira diferença reside. Muitas dessas dificuldades são, inclusive, ditas de origem “psicológica”, como a abolição da palavra “test” nos nomes dos métodos para forçar o pensamento no sentido de uma verificação de comportamento ao invés de um teste de estado (medida defendida através da hipótese de Sapir-Whorf).

De fato, posso afirmar que a maior parte das suítes de testes escritas em RSpec, Shoulda ou test/spec que já tive a oportunidade de examinar (seja trabalhando, seja “navegando” por projetos open source – uma grande fonte de aprendizado), falha miseravelmente na tentativa de adotar o BDD, tropeçando feio em erros como verificar estado ao invés de comportamento, testar funcionalidades da linguagem ou framework e, principalmente, overmocking – chegando ao ponto em que um teste não verifica mais nada, apenas mocks e stubs – o que nos leva a testes quebradiços ou testes que não falham mesmo que você apague o código que eles deveriam verificar.

Esse último item leva a um outro ponto importante (e, aqui, uma visão muito pessoal – acredito ser compartilhada por poucos): acredita-se que o uso de mocks configura o uso do BDD, pois estabelecer expectativas em relação à interfaces e, consequentemente, isolar horizontalmente os componentes testados, passa a ser, “automaticamente”, verificação de comportamento. O uso de mocks não estabelece nada além de uma expectativa de interação – uma interface.

Como um classicista evito o uso de mocks (e dublês em geral), reservando-os para onde realmente é difícil ou pouco prático o uso de um objeto real ou, como deveria ser seu principal uso, uma ferramenta de design de código através da qual modelamos interfaces ainda não existentes à medida em que praticamos o TDD (ou seja, escrevemos testes antes da implementação do código real) – e os substituo assim que a classe real é implementada, quando aplicável.

Então, não acredite que por utilizar alguma ferramenta facilitadora, você, instantâneamente, estará praticando BDD. Estude a técnica e a filosofia envolvida e você poderá utilizá-la com qualquer ferramenta para testes.

Bem, não sou um especialista em testes nem um guru da programação, mas tenho algumas opiniões.

O que é um teste quebradiço (ou “brittle test”)?

Um teste quebradiço é aquele que passa a falhar após uma alteração em código não relacionado ao que ele deveria testar ou quando o código que ele testa é alterado, mas o comportamento do sistema não muda.

Além do custo de manutenção inerente à correção de testes que quebram “sem motivo”, ocorre também um impacto na moral e na motivação dos desenvolvedores. Se um desenvolvedor faz mudanças em um código e, ao integrá-lo, testes começam a falhar por motivos como inconsistência de dados em banco ou alto acoplamento, é praticamente certo que isso irá irritá-lo e, a médio prazo, fazer com que ele abandone os testes, criando verdadeiros “ferros-velhos” de testes sucateados. As quebras se tornarão cada vez mais frequentes e, logo, processos como integração contínua serão completamente abandonados.

Casos comuns

Fixtures

Manter os grafos de objetos através de fixtures torna-se exponencialmente mais complexo à medida que sua aplicação aumenta de tamanho e cria mais relacionamentos entre os objetos. Adicione um atributo ou relacionamento entre modelos e um grande número de testes automaticamente começará a quebrar, exigindo esforço considerável para correção.

Utilize algo como object_daddy e factory_girl que, sim, também precisarão de alguma manutenção após alterações na estrutura de dados, mas exigindo esforço muito menor.

Testes de views em código (usando coisas como assert_tag ou o matcher have_tag)

Esses testes são uma completa e desnecessária perda de tempo. Uma mudança em alguma classe ou nome de campo e, bang!, testes quebrando sem que o comportamento da aplicação tenha sido afetado.

Você pode ser moderado nesses testes e não torná-los muito específicos para evitar isso mas, nesse caso, use algo como o Selenium, também com cuidado, pois é possível cair no mesmo erro com essa ferramenta.

Teste o que influi no comportamento, como o fluxo de redirecionamentos ou elementos com ids utilizados para chamadas ajax.

O Selenium também tem a vantagem de poder ser utilizado por testadores com algum conhecimento de estrutura Html.

Abuso de mocks e stubs

Isto é, para mim, um dos grandes vilões dos testes quebradiços. Esse abuso leva os testes a ficarem altamente acoplados a detalhes de implementação. Por exemplo (o exemplo é bobo, apenas para ilustrar):

class Delivery
  def has_packages?
    self.packages.count > 0
  end
end
 
class DeliveryTest < Test::Unit::TestCase
  context "A scheduled delivery" do
    setup do
      Delivery.stubs(:count).returns(10)
      @delivery = Delivery.new
    end
 
    should "have packages" do
      assert @delivery.has_packages?
    end
  end
end

Se, por um motivo qualquer, a implementação do método has_packages? mudar e passar a utilizar, por exemplo, o método size ao invés de count, o teste passará a quebrar sem que o comportamento tenha sido alterado. O exemplo é simples mas, em casos reais, isso é um grande problema. Note que stubs tendem a deixar os testes mais acoplados do que mocks.

Algumas soluções pra isso são: não utilizar mocks e stubs (o que é um tanto extremista), aumentar o encapsulamento das classes ou aceitar isso e continuar.

Esse tipo de coisa costuma acontecer quando queremos utilizar mocks e stubs para tornarmos os testes independentes de recursos externos, como banco de dados. Nesses casos, o trade-off entre acoplamento do teste ao código e o ganho em velocidade de execução ou tempo de manutenção através do isolamento deve ser avaliado.

Guias gerais

Para evitar testes quebradiços, algumas guias podem ser utilizadas para a maioria dos casos:

• Especifique apenas o que você quer que aconteça e nada mais
• Em termos de mocks e stubs: use stubs para queries (tudo o que retorna dados e não modifica estado) e mocks para comandos (que não necessariamente retornam algo, mas modificam estado)
• Lembre-se de que o que importa é o comportamento do método/classe/sistema. Como isto é implementado, em nível de código, não deve fazer diferença nos seus testes

Como já disse, não sou um especialista. Então, se você percebeu alguma grande besteira nesse post, não exite em discutir, eu tenho a mente aberta.

Update

Note que mocks e stubs, quando usados corretamente, são uma importante ferramenta de design. Esse tipo de ferramenta, além de isolar os testes de recursos externos, tem o intuito (e talvez até o principal objetivo) de servir como apoio à prática do TDD: enquanto escreve os testes antes do código, mocks e stubs (e dublês em geral) permitem que você especifique o comportamento de partes ainda não existentes da aplicação. Nesse processo, torna-se mais fácil detectar falhas como alto acoplamento e corrigí-las o quanto antes, gerando menos stress.

Leia mais:

• Does stubbing make your tests brittle?
• Sorry, you’re just not my type
• Brittle tests
• Mocks aren’t stubs

Matchers são superiores à asserções porque, quando estou conversando com alguém, eu não afirmo “Ei, assira que são iguais: 2, 1+1″, eu afirmo “Ei, 1+1 deve ser igual a 2″.

Bullshit!

Trata-se de uma falácia (Dicto Simpliciter) e bem frágil. O que é óbvio e passa despercebido nesse caso é que Linguagens Específicas de Domínio (Domain Specific Languages, DSLs) não são linguagens naturais. Uh-oh! Tão óbvio.

Você com certeza fica completamente perdido nas discussões médicas do seriado House. Tente conversar com um engenheiro elétrico sobre o processo de geração de energia elétrica numa usina nuclear. Tente entender 20% do que ele fala.

Linguagens específicas de domínio são utilizadas por especialistas no domínio em questão. Então me diga se, dentro de um teste, não está o pragmático desenvolvedor em um domínio muito específico onde, sim, asserções fazem todo o sentido. Nem sequer tente argumentar que especificações (que substituem os malfadados testes do TDD) são feitos para que clientes entendam. Don’t fool yourself.

Matchers não são ruins, não me entenda mal. São, sim, muito legais e legíveis. Mas dizer que asserções “não são naturais” e tentar fazer disso um ponto de superioridade é falta de conhecimento.

Observações: sim, eu prefiro o Shoulda ao RSpec e não vejo problema nenhum na utilização de nenhum dos dois. O ponto aqui é lembrar que DSLs não são inglês ou português, são linguagens muito específicas em um dado contexto. O exemplo citado foi o que me veio à cabeça mais rapidamente, talvez devido ao Rails Summit e à palestra de Jay Fields.

Leia mais:

The ‘Language’ in Domain-Specific Language Doesn’t Mean English (or French, or Japanese, or …)

Nas versões “não-Rest” do Rails, era comum o uso do plugin in_place_editing para conseguir essa funcionalidade. Para as versões mais novas, ainda é possível utilizar esse plugin, mas a solução acaba ficando bem grosseira. Pesquisando sobre isso, encontrei o plugin better-edit-in-place, que permite utilizar a interface Rest padrão do Rails para conseguir a funcionalidade.

Depois de instalar o plugin, você precisa de apenas três passos para fazer tudo funcionar:

1. Escrever/incrementar os testes funcionais do controller (test first, aqui com Shoulda e… ahn… fixtures…):

context "on Ajax PUT to :update" do
  setup do
    xhr :put, :update, :id => emails(:one).id, :email => {:address => 'new_email@email.com'}
  end
 
  should_assign_to :email
  should_respond_with :success
  should_not_set_the_flash
 
  should "update the email address" do
    assert_equal assigns(:email).address, 'new_email@email.com'
  end
end

2. Criar uma ação update no controller do recurso ou adicionar o formato correto ao bloco respond_to:

def update
  @email = Email.find(params[:id])
  @email.update_attribute(:address, params[:email][:address])
  respond_to do |format|
    format.js { render :json => @email }
    format.html #voce que sabe...
  end
end

3. Ajustar seu markup para que a parte JavaScript do plugin funcione. Para isso, basta utilizar um helper disponibilizado pelo plugin:

<%= edit_in_place(email, :address) -%>

Pronto. Ao abrir a página e clicar sobre o elemento span que exibe o texto do atributo passado ao helper, o mesmo será substituído por uma caixa de texto com um botão para salvar e um link para cancelar a ação. Tudo simples e de forma muito mais limpa. O plugin também funciona com recursos aninhados.

Obs: note que ignorei “detalhes” como validação do modelo, entre outros importantes. Fiz isso apenas pra encurtar o post, não faça o mesmo em aplicações reais.

Apenas lendo uma introdução aos named_scopes já dá pra ficar bem empolgado. É um recurso simples e, ao mesmo tempo, poderoso e, quando bem utilizado, pode resulta no código bonito e sucinto que buscamos todo dia.

Vamos, então, explorar mais algumas possibilidades desse recurso.

Modificadores para filtros

Além de estabelecer condições de filtro, podemos aplicar modificadores a eles. Um exemplo é aplicando ordenação:

class User < ActiveRecord::Base
  named_scope :boys, :conditions => ["gender = ?", 'M']
  named_scope :girls, :conditions => ["gender = ?", 'F']
  named_scope :created_since, lambda { |days| {:conditions => ["created_at >= ?", days]}}
 
 #modificando o filtro com ordenação
  named_scope :by_first_name, :order => "first_name ASC"
end

Isso possibilita os seguintes usos:

User.girls.by_first_name
User.boys.by_first_name
 
#ou, somente:
User.by_first_name
 
#encadeando como se não houvesse amanhã e operando sobre o resultado!
User.girls.created_since(5.days.ago).by_first_name.map(&:first_name)

Flexibilizando os escopos

Que tal um filtro aplicável a diferentes atributos do modelo? Vamos lá:

#adding the scope to ActiveRecord::Base so it's available to all models
class ActiveRecord::Base
  named_scope :contains, lambda { |column, text| {:conditions => ["lower(#{column}) LIKE ?", "%#{text.downcase}%"]} }
end

Utilizando:

User.contains(:first_name, "%mat%")
User.contains(:last_name, "Sinclair")
 
#encadeando...
User.boys.contains(:last_name, "S%").by_first_name
 
#enlouquecendo...
User.girls.contains(:first_name, "Je%").created_since(5.days.ago).by_first_name.map(&:first_name)

Mesclando finders dinâmicos e escopos

User.boys.find_all_by_first_name("Peter")

Note que o finder deve ser o último método na cadeia, pois retorna um Array, onde seus escopos não existem:

=> User.find_all_by_first_name("A%").boys
NoMethodError: undefined method `boys' for #<Array:0x21e7bf0>

Testando named_scopes

É claro que temos que testar se os escopos estão formando as condições da maneira que desejamos. Existem alguns métodos que ajudam a fazer isso:

should "correctly generate the 'boys' scope" do
  expected = {:conditions => ["gender = ?", "M"]}
  assert_equal(expected, User.boys.proxy_options)
end

Update Fev/2009: Na verdade, nunca teste named_scopes dessa maneira. Quando estamos desenvolvendo com TDD, não nos interessa saber se algo está codificado numa classe mas, sim, se essa classe possui o comportamento esperado. O teste que coloquei acima apenas verifica se há um named_scope declarado no model e isso, definitivamente, não é bom. Segue um outro exemplo de teste:

setup do
  @boys = []
  3.times do
    @boys << Factory(:user, :gender => "M")
    Factory(:user, :gender => "F")
  end
end
should "be able to list just the users that are boys" do
  assert_equal(@boys, User.boys)
end

Agora sim estamos usando o teste da maneira correta. Não nos importa como esse filtro está escrito, apenas se ele nos proporciona o comportamento esperado.

Observação: os exemplos são para ilustrar o que pode ser feito com esse recurso. Tome muito cuidado com os encadeamentos que executar, sempre observando as queries resultantes. Um pequeno deslize pode significar um gargalo significativo.

Leia mais:
More Named Scope Awesomeness

Na comunidade Rails, os três projetos mais conhecidos na área de BDD são RSpec, Shoulda e test/spec. Minha escolha é o Shoulda, que utilizo desde o lançamento com muito sucesso. Há um bom tempo venho “rascunhando” um screencast introdutório e, finalmente, ele está pronto. Clique aqui para baixá-lo em formato QuickTime.

O objetivo do screencast é apenas mostrar superficialmente o que é Shoulda e como testar funcionalidades de modelos ActiveRecord (como validações e associações). Em breve virão mais alguns cobrindo testes de controllers e mais detalhes sobre o uso do plugin.

Links interessantes:

Shoulda: tutorial | repositório | RDocs | bundle para TextMate

Plugin QuietBacktrace

Comentários, críticas e complementos são muito bem-vindos!

Obs: estou resfriado, mas fiz o possível para deixar o som o mais claro possível. Por favor, avise caso eu não tenha conseguido.

Update: como apontado nos comentários, subi o vídeo sem o som (duh!), mas isso já foi corrigido. Obrigado pelo aviso, pessoal.

Update 2: disponibilizei o script e as imagens que utilizo para o Autotest com o Shoulda em minha máquina, rodando o Leopard. Crie, na pasta home de seu usuário (/Users/<nome_do_seu_usuário>/), uma pasta chamada .autotest_images e copie as duas imagens para lá. Crie, também na home, um arquivo chamado .autotest e preencha-o com o script contido no pacote. Esse script é baseado em um script publicado pelo Carlos Brando.