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.

No entanto, é preciso ter bastante cuidado. Métricas são como muletas: muito úteis quando você não consegue andar sem a ajuda delas mas, se você utilizá-las sem necessidade, vai enfraquecer suas pernas.

Um bom exemplo disso é uma métrica muito utilizada por quem escreve testes: a cobertura de código. É uma ferramenta muito útil quando é preciso “correr atrás” do prejuízo, isto é, adicionar testes a código sem cobertura. Nesse caso, é prática comum estabelecer uma porcentagem de cobertura a ser atingida dentro de um prazo limitado. Mas, se você pratica BDD/TDD consistentemente e não deixa código importante sem cobertura, é realmente necessário confirmar isso com um gráfico ou uma porcentagem?

O uso e confiança cega em métricas mesmo sem necessidade de um amparo como esse pode levar à má aplicação da técnica do desenvolvimento guiado por testes, já que ela passa a ser baseada em um número artificial – é muito fácil ter 100% de cobertura de código com uma suíte de testes ruim. Antes uma suite boa mas que, conscientemente, não passa por cada linha de código do que uma suite que execute cada linha, mas seja um lixo como especificação e ferramenta de refactoring.

Mais um exemplo de fragilidade fica claro no famoso e cantado aos quatro ventos code to test ratio: ao utilizar um framework de testes verboso, é fácil obter uma razão de linhas de teste por linhas de código muito maior do que utilizando um framework mais compacto ou macros. Me desculpe quem utiliza e divulga esse número como algum indicativo de qualidade, mas essa medida é simplesmente ridícula, além de totalmente ilusória.

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.

É muito bom que a mentalidade de testes esteja sendo cada vez mais difundida. Com isso, desenvolvem-se as abordagens às práticas de desenvolvimento orientado por testes como, por exemplo, os frameworks. Enquanto eles se tornam cada vez mais extensíveis, eficientes e com DSLs mais limpas e bonitas, muitas pessoas esquecem que, independentemente da ferramenta, da sintaxe e da abordagem técnica a ser utilizada, a intenção do código desenvolvido é que deve ficar explícita.

Observação: ao longo desse texto, utilizarei a expressão “desenvolvimento orientado por testes”, mas você pode substituir por “desenvolvimento orientado por comportamento” ou qualquer abordagem similar.

O que é a intenção do código?

A intenção do código tem tudo a ver com algo que vem sendo muito discutido: o comportamento do software. Uma definição de comportamento é “a resposta observável de um sistema a um estímulo“. Logo, em última análise, podemos dizer que o que importa é verificar se a resposta observável de um componente de software é a esperada, dado um ou mais estímulos pré-definidos.

Em alguns casos isso significa apenas definir um estado, chamar algum método e verificar o resultado. Em outros, significa verificar também a propagação dos efeitos em outros objetos (caso onde os mocks são muito úteis). Isso vai depender do componente em desenvolvimento e da abordagem utilizada.

Como?

A pergunta é: como testes ajudam a revelar a intenção do código?

Se você escrever um monte de código confuso e, após isso, resolver escrever alguns testes para validar esse trabalho, esses testes não vão ajudar em nada. Mas, se utilizar testes para orientar seu processo de desenvolvimento, descobrirá o papel fundamental que eles terão para criar código claro, fácil de entender, utilizar e modificar. Ao especificar um cenário (o estado pré-definido onde ocorrerá o estímulo), fica muito mais simples projetar e verificar o comportamento necessário.

Geralmente, ao escrever testes antes da implementação, obtêm-se outros benefícios, tais como: uso de boa nomenclatura, simplicidade e facilidade no refactoring. Tudo isso deve-se ao fato de que, ao praticar o desenvolvimento orientado por testes, você efetivamente pensa mais sobre o que vai escrever, antes de o fazer.

Exemplo

Vou tentar exemplificar os passos de criação de um componente simples com e sem testes para orientar a implementação. Assim, ao final, teremos uma perspectiva melhor dos efeitos do processo.

Quero escrever uma aplicação para cadastrar minha coleção de filmes. Preciso de uma classe que representará o filme:

class Movie
  attr_accessor :title
end

Isso é o suficiente para o exemplo.

Agora vamos iniciar o processo de implementação da classe responsável pelo gerenciamento da coleção. Primeiro, sem teste algum.

Sei que preciso de uma classe que possua uma lista de filmes e permita que eu posso adicionar, remover, procurar e listar todos os filmes. Vamos lá:

class MovieShelf
  attr_accessor :movies
 
  def initialize
    @movies = []
  end
 
  def lookup(movie)
    @movies.detect {|m| m == movie}
  end
 
  def list
    @movies.each do |movie|
      puts movie.title
    end
  end
end

Ok, muito simples. Em dois minutos está pronto. Um exemplo de uso (no irb):

>> shelf = MovieShelf.new
=> #<MovieShelf:0x36eb88 @movies=[]>
>> m = Movie.new
=> #<Movie:0x33b328>
>> m.title = "Juno"
=> "Juno"
>> m2 = Movie.new
=> #<Movie:0x39968>
>> m2.title = "Transformers"
=> "Transformers"
>> shelf.movies << m
=> [#<Movie:0x33b328 @title="Juno">]
>> shelf.movies << m2
=> [#<Movie:0x33b328 @title="Juno">, #<Movie:0x39968 @title="Transformers">]
>> shelf.list
Juno
Transformers
=> [#<Movie:0x33b328 @title="Juno">, #<Movie:0x39968 @title="Transformers">]
>> shelf.lookup m2
=> #<Movie:0x39968 @title="Transformers">
>> shelf.movies.delete m2
=> #<Movie:0x39968 @title="Transformers">
>> shelf.list
Juno
=> [#<Movie:0x33b328 @title="Juno">]

Tudo bem, funciona e parece estar de acordo com os requisitos. Mas o código não está muito consistente. A coleção de filmes, que na prática é um objeto da classe Array, está exposta e pode ser manipulada diretamente. Isso pode ser muito ruim caso algum método da classe MovieShelf faça ações adicionais ao operar sobre a coleção. A nomenclatura também não é muito clara, entre outros pequenos problemas. Também não gostei da forma como estou criando os objetos que representam os filmes.

Agora, vamos começar com uma pequena especificação do que é preciso. Com isso, vou ter mais tempo para pensar em bons nomes e numa forma de uso limpa e direta.

context "a movie shelf" do
  setup { @shelf = MovieShelf.new }
 
  should "let the user store a movie" do
    juno = Movie.new("Juno")
    shelf.store juno
    assert shelf.contains?(juno)
  end
end

Somente estabelecendo essa primeira expectativa quanto ao comportamento do componente, já temos idéia de um início de implementação:

class Movie
  attr_accessor :title
 
  def initialize(title)
    self.title = title
  end
end
 
class MovieShelf
  def initialize
    @movies = []
  end
 
  def store(movie)
    @movies << movie
  end
 
  def contains?(movie)
    @movies.include? movie
  end
end

Continuando:

context "a movie shelf" do
  setup { @shelf = MovieShelf.new }
 
  should "show how many movies are stored" do
    juno = Movie.new("Juno")
    transformers = Movie.new("Transformers")
    shelf.store juno
    shelf.store transformers
    assert_equal 2, shelf.movies_count
  end
end

Implementando:

class MovieShelf
  def initialize
    @movies = []
  end
 
  def store(movie)
    @movies << movie
  end
 
  def contains?(movie)
    @movies.include? movie
  end
 
  def movies_count
    @movies.size
  end
end

É claro que o exemplo é bem bobo, mas perceba como a interface fica melhor e também como vamos descobrindo novas funcionalidades ao longo do processo de especificação. Este é um dos principais benefícios do desenvolvimento orientado por testes: interfaces ricas através de código modular, flexível e de intenção clara.

Não vou continuar o exemplo com as demais funcionalidades para não alongar ainda mais o artigo. Acredito que consegui expor aqui a importância da intenção do código e como deixá-la clara e fácil de entender.

O que você pensa sobre isso? Deixe sua opinião, comentário, exemplo, crítica ou sugestão.

Leia também:

• Test Driven Development: Programming by Intention
• The BDD cargo culting

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

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 …)

• Embrace the TDD cycle: this one isn’t Rails related, but is very important. You can write your code first and test it after and you’ll get some benefits, but Test-Driven Development really leverages the power of this automated testing. By writing your tests first you get low coupling and high cohesion through a better interface (API) design. Moreover, by following the red-green-refactor cycle you’ll always know when you’re done and will avoid scope creep.
• Test your helpers: plain and simple. Rais Recipes has a recipe about it and, with Edge Rails, testing helpers got easier.
• Overmocking results in brittle tests:and brittle tests are a bad thing. Many people just mock and stub everything. By doing this you’re coupling your tests to the inner details of the tested code instead of the result of its execution. You can see an example here (and subscribe to that blog’s feed, it’s very good).
• Watch out on your way to BDD: Behavior-Driven Development is in vogue within the Rails community. Be careful. Just like you can write Fortran in any language, you can use something like RSpec and still not do BDD. BDD is about a shift in the way you think about tests, not about tools by themselves. You can use Test::Unit and do BDD. Tools like RSpec and Shoulda (my personal choice) are facilitators, they don’t guarantee anything.
• One assertion per test: this is one of that tips that seems inoffensive but once you’re doing helps a lot. Why? Jay Fields can explain better than me.

And that’s it. Five quick and simple tips that I hope will help you. Feel free to share your own tips in the comments. This article is my entry to the Railscasts’ 100th episode contest. Take some time to visit the site, it’s really good.