Um conjunto de técnicas que podemos utilizar para atingir esse objetivo é chamada de SOLID, um acrônimo que representa cinco técnicas:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

O objetivo desses princípios é fazer com que alterações necessárias sejam feitas no menor número possível de locais no código. Em outras palavras, é diminuir o custo dessas mudanças através de um design que reduz os efeitos colaterais das modificações.

Nesse artigo vou mostrar um pouco sobre a aplicação do Single Responsibility Principle em Ruby.

Esse princípio nos diz que uma classe deve ter apenas uma responsabilidade e deve executá-la por completo (não devem haver outras classes que executem partes dela). É uma forma de conseguir alta coesão, uma qualidade desejável em código orientado a objetos. Uma classe coesa executa completamente uma responsabilidade, ou seja, essa responsabilidade não fica fragmentada e espalhada entre diferentes entidades no domínio.

Uma forma de pensar sobre o que é uma responsabilidade para facilitar a absorção do conceito é que esta representa uma razão para mudar. Então podemos definir o princípio como: uma classe tem uma e apenas uma razão para mudar.

Vamos a um exemplo de um modelo ActiveRecord que viola esse princípio (alerta para pseudo-código que nem deve funcionar, é apenas um exemplo):

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
 
  def get_official_price
    open("http://thegamedatabase.com/api/game/#{name}/price?api_key=ek2o1je")
  end
 
  def print
    <<-EOF
      #{name}, #{platform}, #{year}

      current value is #{get_official_price}
    EOF
  end
end

Esse modelo tem como sua responsabilidade principal cuidar da lógica de negócio ligada à entidade Game. Porém, como podemos ver aqui, ele também está responsável por consultar um webservice para obter a cotação do jogo e por formatar sua exibição. Essa implementação possui baixa coesão pois essa classe possui mais de um motivo para mudar. Ela será alterada se os requisitos de validação de dados mudarem, se algum detalhe da chamada do webservice mudar ou se precisarmos exibir seus dados numa formatação diferente.

Uma forma de resolver isso seria desmembrar essa classe tendo esse resultado:

class Game < ActiveRecord::Base
  belongs_to :category
  validates_presence_of :title, :category_id, :description,
                        :price, :platform, :year
end
 
class GamePriceService
  attr_accessor :game
 
  # we could use a config file
  BASE_URL = "http://thegamedatabase.com/api/game"
  API_KEY = "ek2o1je"
 
  def initialize(game)
    self.game = game
  end
 
  def get_price
    data = open("#{BASE_URL}/#{game.name}/price?api_key=#{API_KEY}")
    JsonParserLib.parse(data)
  end
end
 
class GamePrinter
  attr_accessor :game
 
  def initialize(game)
    self.game = game
  end
 
  def print
    price_service = GamePriceService.new(game)
    <<-EOF
      #{game.name}, #{game.platform}, #{game.year}

      current value is #{price_service.get_price[:value]}
    EOF
  end
end

Assim aumentamos bastante a coesão de nosso sofware. Cada classe possui apenas uma razão para mudar e atende ao SRP.

Um exemplo mais real pode ser visto no modelo Creditcard do Spree. Note que, entre outras coisas, o modelo também é responsável pelos processos de compra e autorização do cartão (métodos purchase e authorize). Note como esse métodos implementam parte do processo e delegam outras partes para outros componentes quando a responsabilidade deveria ser 100% realizada em outra parte. Isso cria baixa coesão (múltiplas responsabilidades por classe) e alto acoplamento (uma responsabilidade dividida por várias classes interdependentes).

Como um exercício a parte podemos pensar sobre até que ponto modelos do ActiveRecord quebram o SRP por serem responsáveis por persistência e lógica de negócios (que inclui validação de dados). Há muitos desenvolvedores dos dois lados nessa questão. Acredito que há pequenas violações mas de uma forma não prejudicial, já que a persistência é implementada por uma classe especializada e apenas herdada em nossos modelos, de forma que essa é delegada ao framework (que cuida de possíveis modificações necessárias à persistência).

É preciso ter em mente que ser muito extremista com esses princípios também pode levar à problemas e a um excesso de preciosismo que torna-se prejudicial.

Bom, a partir daqui vamos para outros artigos onde serão explorados os outros princípios. O pseudo-código utilizado no exemplo acima ainda tem algumas coisas a ganhar através da aplicação de outros princípios.

Leitura recomendada:

• Cohesion
• Coupling
• Separation of concerns

Bem, não me preocupei muito com o motivo disso. Busquei algumas maneiras de formatar essa saída e, entre outras, encontrei a gem turn. Configurei-a no Gemfile do projeto e tudo funcionou perfeitamente de primeira, sem nenhum incômodo. Além da formatação, uma feature interessante é que, ao invés de mostrar pontinhos e letras (ex: …..F…F.), o turn vai mostrando as descrições dos testes e seu status (passou/falhou) à medida que a suite é executada. Feedback bem mais útil.

Veja um exemplo de como fica a formatação através desse link: http://d.pr/mWPe (assim não quebro todo o layout do blog).

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.