Com o amadurecimento da ideia e algumas alterações no código, foi possível tornar a biblioteca totalmente transparente do ponto de vista do subject a partir da versão 0.2.0. Segue um exemplo (ignore a “inocência” do código):

class User
  def save
    ...
  end
end
 
class UserObserver
  include Sentinel
 
  observe User, :save
 
  def self.notify(*args)
    #método chamado antes de user.save
  end
end

Uma atual limitação é que a interceptação é sempre feita pelo método de classe notify do Observer. O plano é que isso seja flexibilizado em breve.

Existem algumas bibliotecas open source que implementam Observers em Ruby e até mesmo uma na própria linguagem. Porém, queria que a implementação fosse transparente, sem alterar nada no método observado, nem mesmo adicionando uma chamada para notificar os observers, como é feito na implementação mais comum. Daí nasceu a ideia de criar uma pequena biblioteca provendo essa funcionalidade através do recurso de aliasing do Ruby e o resultado foi batizado de Sentinel, disponibilizado como uma gem.

Com essa gem, é possível interceptar chamadas a métodos de instância ou de classe através de um simples mixin (veja o Readme da gem para mais informações). De forma declarativa, definimos qual o método a ser observado e qual será o Observer notificado (qualquer objeto que responda ao método notify).

Sinta-se à vontade para sugerir modificações e notificar erros.

Formatação padrão do logger

Pouco depois, resolvi utilizar o ActiveRecord (que carrega junto o ActiveSupport) no script. Feito isso, o output do logger mudou para:

Formatação com ActiveSupport

Isso não é bom. Pesquisei um pouco e descobri que o ActiveSupport modifica a formatação padrão utilizando uma classe chamada SimpleFormatter ao invés da classe Formatter padrão do logger.

Desta forma, recuperar a formatação original é simples, basta modificar o formater utilizado pela sua instância do logger:

log = Logger.new(STDOUT)
log.datetime_format = "%d-%m-%Y %H:%M:%S"
 
# Recuperando a formatação original
log.formatter = Logger::Formatter.new

Também é possível alterar o formatter padrão na classe Logger. Dessa forma todas as instâncias utilizarão o formato padrão:

# Fazer isso após carregar o ActiveSupport para reverter a alteração do formatter
class Logger
  def formatter
    @formatter = Formatter.new
  end
end

Testes devem ser extremamente legíveis. Não deve existir sobrecarga cognitiva, isto é, não deve ser necessário entender o código do teste para então entender o comportamento que ele especifica – isso deve ficar claro rapidamente. Exemplos de sobrecarga são a necessidade de “ficar pulando” entre vários arquivos ou “descriptografando” lógica mágica para entender o código do teste.

É fácil, então, identificar dois tipos de recursos que podem causar problemas no entendimento dos testes – há uma tênue linha separando o bom e o mal uso deles: macros e “magia negra” em forma de código Ruby.

Macros devem ser utilizadas com muito cuidado. É interessante utilizar macros que encapsulam código simples para economizar tempo na criação dos testes, como essa macro para especificar ações autenticadas com o Authlogic:

def login_as(user)
  activate_authlogic   #this is from Authlogic::TestCase
  UserSession.create({:email => user.email, :password => user.password})
end

Macros com muito código ou que utilizam outras macros devem ser evitadas.

Um problema provavelmente mais grave é a utlização de algumas técnicas de “magia negra” no código. Aquela técnica super obscura e bacana envolvendo o Enumerable que você viu num blog esses dias não deve ser usada nos testes (nem na lógica de negócios, na minha opinião): foque sempre nos idiomas comuns da linguagem. Por simples falha da minha memória agora, segue um exemplo bobo, mas válido:

# truque menos conhecido
%w(this is a test) * ", "    #=> "this, is, a, test"
 
# idioma comum
%w(this is a test).join(", ")    #=> "this, is, a, test"

Os testes, quando usados corretamente, também são a porta de entrada de novos desenvolvedores ao código já existente na aplicação. Pode ser que sua equipe seja formada por Rubistas experientes que conheçam todos os truques envolvidos, mas a adaptação de um profissional com menos experiência na linguagem pode ser muito facilitada por testes com código simples e altamente legível, mesmo que isso “custe” alguma repetição ou uso de construções mais comuns.

A conclusão é: em todo seu código e principalmente nos testes, evite o uso de macros que escondem muito código ou lógica relevante ao comportamento especificado e também prefira idiomas comuns, mesmo que você saiba técnicas “ninja” da linguagem.

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.

Para iniciar o irb já com essa lib carregada, basta executar o comando: irb -r rbconfig (a flag -r diz ao irb para carregar uma lib ao iniciar). Para obter algumas configurações da instalação Ruby, acesse o hash Config::CONFIG. Veja alguns exemplos (clique para ver a imagem maior):

Nota: em algumas instalações, essa biblioteca já é carregada com o irb por padrão.

Com esse tipo de uso surgem alguns problemas, tais como over-mocking e over-stubbing, ou seja, o uso abusivo de mocks e stubs. O abuso de mocks torna seus testes quebradiços, isto é, testes que falham sem que haja alteração de comportamento do componente sob verificação. O abuso de stubs torna seus testes fracos, isto é, testes que saem de sincronia com o código, verificando comportamento que já não é real, mas continuam passando.

Um exemplo de abuso de mocks:

it "should be successful" do
  Account.expects(:new).with(:current_user => @user, :first_name => "Test", :last_name => "Test").returns(@account)
  @account.expects(:login_method=).with(CONFIG::LOGIN::OpenID)
  @account.expects(:has_email_and_password=).at_least_once
  @account.expects(:has_openid=).twice
  do_edit
  response.should be_success
  response.should render_template("edit")
end

Note que até métodos de atribuição são colocados sob expectativas. Se a implementação sofrer uma alteração simples, fazendo, por exemplo, com que algum desses métodos não seja mais chamado, mesmo que não haja qualquer modificação no comportamento, o teste falhará.

Um exemplo do abuso de stubs:

it "has been modified a lot of times" do
  Dependency.stubs(:a_method)
  NoLongerADependency.stubs(:something).returns(false)
  AnotherDependency.stubs(:nonexistent_method).returns(10)
  MyClass.new.do_something
end

Com esse tipo de abordagem, você pode acabar com problemas como fazer stubs de métodos que não existem mais ou até mesmo de objetos que já não são mais uma dependência.

Uma forma de evitar isso com o Mocha (além, é claro, de estudar o uso correto das ferramentas) é utilizar algumas configurações providas pelo framework através de sua classe Configuration:

Mocha::Configuration.prevent(:stubbing_non_existent_method) #impede stubbing de métodos inexistentes
 
Mocha::Configuration.prevent(:stubbing_method_unnecessarily) #impede stubbing de métodos não utilizados
 
Mocha::Configuration.prevent(:stubbing_non_public_method) #impede stubbing de métodos não-públicos
 
Mocha::Configuration.prevent(:stubbing_method_on_non_mock_object) #impede stubbing em objetos "reais"

Nos exemplos acima, caso encontre um dos usos “indevidos”, o Mocha lançará uma exceção do tipo Mocha::StubbingError. Isso ocorre por termos utilizado o método prevent. Há outras configurações possíveis, sendo providos três nívels de configuração:

# padrão - permite a condição
Mocha::Configuration.allow(condition)
 
# apenas emite um aviso quando ocorre a condição
Mocha::Configuration.warn_when(condition)
 
# lança um erro quando ocorre a condição
Mocha::Configuration.prevent(condition)

Essas configurações podem ser um auxílio para o aprendizado do uso correto e equilibrado da ferramenta.

Leia mais:
Mocha::Configuration RDoc
Mocha Configuration – James Mead

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

>> h = {:foo => "bar"}
=> {:foo=>"bar"}
>> h[:other_foo]
=> nil

Você pode adicionar um bloco para tratar esses casos:

>> h = Hash.new { |hash, key| "#{key} is not here"}
=> {}
>> h[:foo]
=> "foo is not here"

É possível, inclusive, alterar o hash em questão:

>> h = Hash.new { |hash, key| hash[key] = "value for #{key}" }
=> {}
>> h[:foo]
=> "value for foo"