Em algumas casos, a repetição será inevitável e mesmo necessária para deixar o código mais legível. Geralmente, entretanto, repetição significa código que ainda não está DRY o suficiente.

Instalação

Para instalar o Flay, basta rodar o comando gem:

~$ sudo gem install flay

Esse comando instala a gem em si e um executável que pode ser usado na linha de comando.

Um exemplo

Para demonstrar o uso da ferramenta, vamos rodar o Flay contra o código mais recente do Active Record:

O resultado (um trecho apenas), depois de alguns minutos de trabalho com a CPU a 100%, é o seguinte:

Matches found in :defn (mass = 290)
  ./test/cases/associations/join_model_test.rb:237
  ./test/cases/associations/join_model_test.rb:262
  ./test/cases/associations/join_model_test.rb:271
  ./test/cases/associations/join_model_test.rb:623
  ./test/cases/associations/join_model_test.rb:650

Matches found in :defn (mass = 270)
  ./test/cases/validations_test.rb:929
  ./test/cases/validations_test.rb:937
  ./test/cases/validations_test.rb:945
  ./test/cases/validations_test.rb:953
  ./test/cases/validations_test.rb:961
  ./test/cases/validations_test.rb:969

Matches found in :defn (mass = 236)
  ./test/cases/validations_i18n_test.rb:491
  ./test/cases/validations_i18n_test.rb:510
  ./test/cases/validations_i18n_test.rb:529
  ./test/cases/validations_i18n_test.rb:549

Matches found in :scope (mass = 204)
  ./test/migrations/duplicate/3_innocent_jointable.rb:12
  ./test/migrations/interleaved/pass_1/3_innocent_jointable.rb:12
  ./test/migrations/interleaved/pass_2/3_innocent_jointable.rb:12
  ./test/migrations/interleaved/pass_3/3_innocent_jointable.rb:12
  ./test/migrations/missing/4_innocent_jointable.rb:12
  ./test/migrations/valid/3_innocent_jointable.rb:12

Matches found in :call (mass = 172)
  ./test/models/author.rb:64
  ./test/models/project.rb:17

Matches found in :defn (mass = 171)
  ./test/cases/validations_test.rb:977
  ./test/cases/validations_test.rb:991
  ./test/cases/validations_test.rb:1079

Note especialmente código que está sendo repetido em arquivos diferentes. No caso acima, como o código está em arquivos de teste, é provável que a repetição seja desejável para não poluir o escopo dos mesmos.

Vamos tomar um outra caso na biblioteca em si:

Matches found in :if (mass = 165)
  ./lib/active_record/associations/has_and_belongs_to_many_association.rb:82
  ./lib/active_record/associations/has_many_association.rb:100
  ./lib/active_record/associations/has_many_through_association.rb:194

O código repetido em questão é o seguinte:

if @reflection.options[:counter_sql]
  @counter_sql = interpolate_sql(@reflection.options[:counter_sql])
elsif @reflection.options[:finder_sql]
  # replace the SELECT clause with COUNT(*), preserving any hints within /* ... */
  @reflection.options[:counter_sql] = @reflection.options[:finder_sql].sub(/SELECT (\/\*.*?\*\/ )?(.*)\bFROM\b/im) { "SELECT #{$1}COUNT(*) FROM" }
  @counter_sql = interpolate_sql(@reflection.options[:counter_sql])
else
  @counter_sql = @finder_sql
end

Vendo os arquivos, é possível observar que o código é o mesmo. Considerando que os três arquivos representam classes com um pai em comum seria possível reduzir a repetição movendo o código para um método a classe pai.

Esse tipo de repetição tende a sumir com refatoramentos e o código acima provavelmente sumirá por um processo similar (alguém se habilita para um patch?).

Conclusão

Como é possível perceber, o Flay representa mais uma forma de observar o seu código em busca de coisas que podem ser melhoradas. É claro que isso não deve ser converter em uma obsessão de remover toda e qualquer repetição, o que demoraria mais tempo do que codificar coisas novas.

Como de usual, sugestões, críticas e dúvidas são bem-vindos.

Instalação

Para instalar o Flog, basta rodar o comando gem:

~$ sudo gem install flog

Esse comando instala a gem em si e um executável que pode ser usado na linha de comando.

Um programa de exemplo

Para demonstrar o uso da ferramenta, vamos utilizar o mesmo exemplo que mostrarmos no artigo sobre o uso do Saikuro.

require "test/unit"

class DocumentHasher

  def initialize(object, options = {})
    @object = object
    @options = options
  end

  def hash
    hash = { :id => @object.id }
    if @options[:fields]
      @options[:fields].each do |field|
        hash[field] = @object.send(field)
      end
    end
    if @options[:extra_fields]
      @options[:extra_fields].each do |field|
        hash[field] = @object.send(field.to_s + "_field")
      end
    end
    hash
  end

  def self.hash(object, options = {})
    self.new(object, options).hash
  end

end

class DocumentHasherTest < Test::Unit::TestCase

  Struct.new("HashExample", :id, :title, :author)

  TITLE_FIELD = "Test"
  AUTHOR_FIELD = "Author"
  EXTRA_FIELD = "Extra"

  def setup
    @object = Struct::HashExample.new(1, TITLE_FIELD, AUTHOR_FIELD)
    class << @object
      def extra_field
        "Extra"
      end
    end
  end

  def test_hash_id
    result = DocumentHasher.hash(@object)
    assert_equal 1, result[:id]
  end

  def test_hash_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author])
    assert_equal TITLE_FIELD, result[:title]
    assert_equal AUTHOR_FIELD, result[:author]
  end

  def test_hash_extra_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author], 
      :extra_fields => [:extra])
    assert_equal EXTRA_FIELD, result[:extra]
  end

end

Salve esse arquivo para um arquivo chamado hasher.rb e rode-o com o comando abaixo para verificar sua execução:

~$ ruby hasher.rb

Utilização

Com esse programa, podemos rodar o Flog. O comando é simples:

~$ flog hasher.rb

Resultado inicial

O resultado da execução acima pode ser visto na listagem abaixo:

Total Flog = 57.7 (7.2 +/- 62.8 flog / method)

DocumentHasher#hash: (27.3)
     9.0: send
     8.6: assignment
     5.8: []
     5.4: branch
     2.8: each
     1.9: to_s
     1.7: +
     1.5: new
     1.3: hash
     1.3: id
DocumentHasherTest#setup: (8.3)
     6.5: sclass
     1.3: assignment
     1.3: new
     0.4: lit_fixnum

Note que o método hash possui um fator de “tortuosidade” de 27 e que os maiores culpados são o envio de mensagens (send) e atribuições. A “tortuosidade” total do programa está em 57.7, que representa o cômputo de todos os métodos do programa.

Alterando o programa

Para fins de exemplo, podemos tentar reduzir a complexidade do método hash como fizemos no artigo anterior usando o exemplo abaixo:

require "test/unit"

class DocumentHasher
  
  def initialize(object, options = {})
    @object = object
    @options = options
  end
  
  def hash  
    hash = { :id => @object.id }
    build_fields(hash, @options[:fields] || {})
    build_extra_fields(hash, @options[:extra_fields] || {})
    hash
  end
  
  def self.hash(object, options = {})
    self.new(object, options).hash
  end
  
  protected
  
  def build_fields(hash, fields)
    fields.each do |field|
      hash[field] = @object.send(field)
    end
  end
  
  def build_extra_fields(hash, fields)
    fields.each do |field|
      hash[field] = @object.send(field.to_s + "_field")
    end
  end    
  
end

class DocumentHasherTest < Test::Unit::TestCase
  
  Struct.new("HashExample", :id, :title, :author)
  
  TITLE_FIELD = "Test"
  AUTHOR_FIELD = "Author"
  EXTRA_FIELD = "Extra"
  
  def setup
    @object = Struct::HashExample.new(1, TITLE_FIELD, AUTHOR_FIELD)
    class << @object
      def extra_field
        "Extra"
      end
    end
  end
  
  def test_hash_id
    result = DocumentHasher.hash(@object)
    assert_equal 1, result[:id]
  end

  def test_hash_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author])
    assert_equal TITLE_FIELD, result[:title]
    assert_equal AUTHOR_FIELD, result[:author]    
  end

  def test_hash_extra_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author], 
      :extra_fields => [:extra])
    assert_equal EXTRA_FIELD, result[:extra]
  end
  
end

Rodando o comando novamente, teríamos:

Total Flog = 58.1 (5.3 +/- 10.3 flog / method)

DocumentHasher#hash: (10.7)
     3.2: []
     3.0: branch
     2.6: assignment
     1.5: new
     1.3: build_extra_fields
     1.3: hash
     1.3: build_fields
     1.3: id
DocumentHasher#build_extra_fields: (9.4)
     4.2: send
     2.8: assignment
     1.8: to_s
     1.6: +
     1.3: branch
     1.3: each
DocumentHasherTest#setup: (8.3)
     6.5: sclass
     1.3: assignment
     1.3: new
     0.4: lit_fixnum
DocumentHasherTest#test_hash_fields: (7.0)
     3.0: []
     2.6: assert_equal
     1.3: hash
     1.3: assignment

Note que a complexidade dos métodos caiu substancialmente. Os métodos estão mais simples e mais balanceados. A “tortuosidade” geral subiu um pouco com a adição de algumas chamadas, mas, analisando os métodos individualmente é possível observar que a somatória de complexidade dos três métodos envolvidos é menor do que a complexidade original. Mais uma vez, o código está mais legível e mais testável.

Conclusão

O Flog representa uma métrica arbitrária de complexidade que, mesmo assim, pode ser usada para acompanhar o desenvolvimento de um base de código. Um exemplo disso pode ser visto no texto do Carlos Villela mostrando a evolução do código do Rails ao longo dos anos.

Como de usual, sugestões, críticas e dúvidas são bem-vindos. No próximo artigo, esfolando o seu código Ruby com mais ferramentas de análise de complexidade.

Instalação

Para instalar o Saikuro, basta rodar o comando gem:

~$ sudo gem install Saikuro

Esse comando instala a gem em si e um executável que pode ser usado na linha de comando.

Um programa de exemplo

Para demonstrar o uso da ferramenta, vamos utilizar um programa de referência. Esse programa será um simples transformador de objetos Ruby em hashes equivalentes e está listado abaixo, com os testes necessários:

require "test/unit"

class DocumentHasher

  def initialize(object, options = {})
    @object = object
    @options = options
  end

  def hash
    hash = { :id => @object.id }
    if @options[:fields]
      @options[:fields].each do |field|
        hash[field] = @object.send(field)
      end
    end
    if @options[:extra_fields]
      @options[:extra_fields].each do |field|
        hash[field] = @object.send(field.to_s + "_field")
      end
    end
    hash
  end

  def self.hash(object, options = {})
    self.new(object, options).hash
  end

end

class DocumentHasherTest < Test::Unit::TestCase

  Struct.new("HashExample", :id, :title, :author)

  TITLE_FIELD = "Test"
  AUTHOR_FIELD = "Author"
  EXTRA_FIELD = "Extra"

  def setup
    @object = Struct::HashExample.new(1, TITLE_FIELD, AUTHOR_FIELD)
    class << @object
      def extra_field
        "Extra"
      end
    end
  end

  def test_hash_id
    result = DocumentHasher.hash(@object)
    assert_equal 1, result[:id]
  end

  def test_hash_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author])
    assert_equal TITLE_FIELD, result[:title]
    assert_equal AUTHOR_FIELD, result[:author]
  end

  def test_hash_extra_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author], 
      :extra_fields => [:extra])
    assert_equal EXTRA_FIELD, result[:extra]
  end

end

Salve esse arquivo para um arquivo chamado hasher.rb e rode-o com o comando abaixo para verificar sua execução:

~$ ruby hasher.rb

Utilização

Com esse programa, podemos rodar o Saikuro. O comando é simples:

~$ saikuro -c -t -y 0 -w 11 -e 16 -i hasher.rb -o report

Esse comando roda o analisador de complexidade com os seguintes parâmetros:

• -t, para analisar tokens também
• -y 0, para exibir a complexidade de todos os métodos
• -w 11, para exibir warnings para métodos de complexidade superior a 11
• -e 16, para exibir erros para métodos de complexidade superior a 16
• -i hasher.rb, o arquivo a ser analisado (pode ser um diretório também)
• -o report, o diretório onde gerar o relatório de saída

Resultado inicial

O resultado da execução acima pode ser visto, parcialmente, na imagem abaixo, que mostra os resultados somente para a classe em que estamos interessados:

Note que o método hash possui complexidade 5 que reflete os 4 comandos decisórios (2 if e 2 each) mais um ponto de saída pelo cálculo mais simples da complexidade. Os demais métodos, puramente lineares, possuem complexidade 1.

No diretório de resultado há também um arquivo que mostra a quantidade de tokens gerados no programa. Este relatório, com os níveis de aviso baixo, tende a reportar erros mesmo em condições consideradas normais.

Alterando o programa

Para fins de exemplo, podemos tentar reduzir a complexidade do método hash. Digamos que façamos a seguinte alteração:

require "test/unit"

class DocumentHasher
  
  def initialize(object, options = {})
    @object = object
    @options = options
  end
  
  def hash  
    hash = { :id => @object.id }
    build_fields(hash, @options[:fields] || {})
    build_extra_fields(hash, @options[:extra_fields] || {})
    hash
  end
  
  def self.hash(object, options = {})
    self.new(object, options).hash
  end
  
  protected
  
  def build_fields(hash, fields)
    fields.each do |field|
      hash[field] = @object.send(field)
    end
  end
  
  def build_extra_fields(hash, fields)
    fields.each do |field|
      hash[field] = @object.send(field.to_s + "_field")
    end
  end    
  
end

class DocumentHasherTest < Test::Unit::TestCase
  
  Struct.new("HashExample", :id, :title, :author)
  
  TITLE_FIELD = "Test"
  AUTHOR_FIELD = "Author"
  EXTRA_FIELD = "Extra"
  
  def setup
    @object = Struct::HashExample.new(1, TITLE_FIELD, AUTHOR_FIELD)
    class << @object
      def extra_field
        "Extra"
      end
    end
  end
  
  def test_hash_id
    result = DocumentHasher.hash(@object)
    assert_equal 1, result[:id]
  end

  def test_hash_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author])
    assert_equal TITLE_FIELD, result[:title]
    assert_equal AUTHOR_FIELD, result[:author]    
  end

  def test_hash_extra_fields
    result = DocumentHasher.hash(@object, 
      :fields => [:title, :author], 
      :extra_fields => [:extra])
    assert_equal EXTRA_FIELD, result[:extra]
  end
  
end

Rodando o comando novamente, teríamos:

Como os testes demonstram, o programa funciona da mesma forma. E como o relatório de complexidade também demonstra, a complexidade do programa permanece a mesma no geral e a dos métodos diminuiu. O resultado é um programa mais legível e mais facilmente testável.

Conclusão

Embora métricas em si não tenham nenhum poder de tornar o código de um programa melhor, acompanhar a evolução das mesmas é uma ferramenta fundamental para garantir a qualidade do código. Para quem usa o Ruby, o Saikuro é uma ferramenta simples e rápida para isso. Para quem não usa, é fácil achar ferramentas que se adequam a outras linguagens.

Como de usual, sugestões, críticas e dúvidas são bem-vindos. No próximo artigo, ainda hoje, esfolando o seu código Ruby com mais ferramentas de análise de complexidade.

Complexidade Ciclomática

Neste quarto artigo, vamos tratar um pouco de complexidade ciclomática. Apesar do nome esdrúxulo, complexidade ciclomática (também conhecida como complexidade condicional) é uma métrica simples para determinar, como o próprio nome sugere, a complexidade de um programa estruturado (cíclico).

Essa métrica foi desenvolvida em 1976 por Thomas J. McCabe e reflete diretamente o número de caminhos independentes que um programa pode tomar durante a sua execução.

Qualquer desenvolvedor que já tenha testado código em sua vida, sabe que a quantidade de testes necessária para exercitar um determinado trecho de código é diretamente proporcional à sua árvore decisória. Em outras palavras, quanto mais caminhos o código puder tomar (seja por meios de condicionais ou loops), maior a quantidade de testes necessários. E como veremos abaixo, há realmente uma relação direta entre a complexidade ciclomática e a cobertura de um código.

Calculando a complexidade ciclomática

Antes de mostrar exatamente como o cálculo pode ser feito, vamos observar algumas coisas em relação a um programa qualquer. Digamos que você esteja desenvolvendo um programa que lhe dê o maior divisor comum entre dois números. Uma fórmula simples é o algoritmo de Euclides que pode ser descrito da seguinte forma:

Dados dois números naturais a e b, verifique se b é zero. Se sim, a é o maior divisor comum entre os mesmos; caso contrário, repita o processo usando b e o resto da divisão de a por b.

Esse algoritmo pode ser expresso pelo seguinte programa em Ruby (note que ele não está em Ruby idiomático):

require "test/unit"

def euclid(m, n)
  if n > m
    r = m
    m = n
    n = r
  end
  r = m % n
  while r != 0
    m = n
    n = r
    r = m % n
  end
  n
end

class EuclidTest < Test::Unit::TestCase
  
  SETS = [[5, 10,  5], [2,  6,  2], [11,  7,  1], 
    [80, 64, 16], [2, 2, 2]]
  
  def test_euclid
    SETS.each do |set|
      assert_equal set[2], euclid(set[0], set[1])
    end
  end
  
end

Se o programa acima for executado, ele rodará o caso de teste logo abaixo da função que verificará se a mesma está correta. Você pode adicionar mais casos ao conjunto SETS se desejar.

A função euclid pode ser descrita por um grafo simples que conecta os caminhos entre as várias declarações que a mesma contém. Esse grafo é o mostrado abaixo (clique para expandir):

Com base nesse grafo, podemos definir a complexidade ciclomática de um programa da seguinte forma:

CC = A - N + 2C

Nessa fórmula:

• CC é a complexidade ciclomática
• A é o número de arestas do grafo
• N é o número de nós do grafo
• C é o número de componentes conectados

Como se trata de uma função simples com um único ponto de entrada e saída, o número de componentes é 1 e a fórmula pode ser reduzida para:

CC = A - N + 2

Se a função possuísse múltiplos pontos de saída, entretanto, a complexidade ciclomática seria definida como:

CC = A - N + C + R

Nessa fórmula, R é o número de declarações de saída (em Ruby, o número de returns).

Voltando ao grafo mostra na figura, vemos que o mesmo possui 11 nós e 12 arestas, o que nós dá uma complexidade ciclomática de 12 - 11 + 2, ou seja, 3.

Uma outra maneira bem simples de descobrir a complexidade ciclomática é contar o número de loops fechados no grafo (que são formados por condicionais e loops) e somar ao número de pontos de saída. No grafo acima, temos 2 loops fechados (os if e while) e um ponto de saída, resultando no mesmo valor 3 para a complexidade da função.

Uma coisa interessante é que a complexidade permanece a mesma quando a sintaxe de uma linguagem é levada em questão sem alterar a semântica do programa. Tome por exemplo a versão idiomática do algoritmo em Ruby:

def euclid(m, n)
  m, n = n, m if n > m
  m, n = n, m % n while m % n != 0
  n
end

O grafo gerado nesse caso é (clique para expandir):

Node que embora o número de nós e arestas tenha mudado, a relação entre eles não mudou e a complexidade permanece a mesma.

Testando

De uma forma geral, o valor da complexidade ciclomática define um limite superior para a quantidade de testes necessários para cobrir todos os caminhos decisórios no código em questão. Esse é um limite superior já que nem todos os caminhos são necessariamente realizáveis.

Disso se infere que quanto menor a complexidade, menor a quantidade de testes necessários para o método em questão. Esse fato implica em outro curioso: quebra um método em vários reduz a complexidade dos métodos mas aumenta a complexidade geral do código e, de forma geral, mantém a testabilidade do programa completo no mesmo nível.

Referências

Obviamente, já que a complexidade é um valor específico, é possível extrair da mesma uma referência. Baseado no trabalho de McCabe, esses valores de referência são:

• 1-10, métodos simples, sem muito risco
• 11-20, métodos medianamente complexos, com risco moderado
• 21-50, métodos complexos, com risco alto
• 51 ou mais, métodos instáveis de altíssimo risco

Conclusão

Essa foi uma pequena introdução ao assunto com o objetivo de abrir o caminho para artigos posteriores mostrando ferramentas de apoio ao cálculo e monitoramento da complexidade ciclomática. Como de usual, sugestões e correções são bem vindos.

Um conselho dele em particular me parece a melhor consideração sobre o assunto. Falando sobre mocks e stubs, ele diz:

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.

Chamo a atenção para a parte final: algumas vezes, você tem simplesmente que aceitar que alguns testes devem ser de certa forma para garantir uma cobertura mais compreensiva.

Dito isso, seguem algumas dicas para testes melhores:

Mocks e Stubs

Uma regra simples que pode ajudar a entender quando usar essas duas técnicas é a seguinte: Se o comportamento esperado deve ser conhecido, use mocks e stubs. Caso contrário, não.

Isso torna fácil perceber que testes de modelos–no caso do Rails, por exemplo–raramente (ou nunca) deve usar essas técnicas. Quando se trata do domínio da aplicação, encapsulamento é uma propriedade básica de sistemas orientados a objetos que não deve ser violada se possível. Obviamente, abstrações vazam; mas isso não deve ser uma desculpa para quebrá-las em testes.

Não teste a abstração imediatamente inferior

Se você está usando Rails, por exemplo, não faz o menor sentido testar a abstração inferior. É muito comum ver testes como:

it "should return all current books" do
  Book.current.proxy_options.should == { :conditions => { :current => true } }
end

Esse tipo de teste verifica se o Rails está funcionando da maneira como deve funcionar e não se o seu código está correto. O resultado é que pequenas mudanças e principalmente a introdução de algum comportamento ortogonal pode quebrar completamente a aplicação enquanto o teste continua a funcionar.

Digamos, por exemplo, que você agora tenha que usar alguma esquema de caching em sua aplicação. No interesse de que a abstração não vaze, você envolve o método acima em alguma abstração que faça isso. O teste acima provavelmente quebrará de imediato, porque está testando a abstração inferior e não o comportamento da aplicação.

O teste correto, nesse caso, seria verificar se a lista retorna é realmente correta, mesmo que isso envolva alguma manipulação de dados que reduza a velocidade do teste.

Use testes de sanidade

Conversamente, é importante também ter alguns testes de sanidade. Às vezes é necessário saber se alguma coisa está declarada, mesmo que a forma final daquela declaração não seja importante.

Um exemplo disso são testes em views. Geralmente, testar se algum conteúdo está aparecendo em uma view é inteiramente desnecessário e pode gerar testes que devem ser refeitos a cada pequena mudança para se adaptar a novas condições.

Mesmo assim, em alguns casos é importante a existência de testes que correm esse risco como forma de testar a sanidade da aplicação; em outras palavras, testar se condições básicas estão sendo supridas.

Não teste nada que não seja público

Uma pergunta muito comum em listas de discussão é como testar métodos privados ou protegidos de uma classe. A reposta geralmente envolve o uso de reflexão e violação de abstrações.

Um exemplo comum seria o código abaixo:

it "should prepare the environment" do
  Manager.send(:prepare_environment)
  Manager.environment.name.should == "development"
end

A resposta correta deveria ser: nunca faça isso. Se seus testes contém alguma necessidade desse tipo, você está violando o encapsulamento e isso indica alguma problema arquitetural mais básico da aplicação. Provavelmente alguma necessidade de separação de dependências que você ainda não identificou.

Nesse casos, funcionalidade básica que envolva código encapsulado pode ser melhor testada pelo seu efeito em outras partes da aplicação.

Cuidado com a ordem dos seus testes

Uma coisa interessante é tentar rodar os seus testes em ordem arbitrária. Existe opções para isso em alguns dos frameworks existentes que podem ajudar a identificar dependências escondidas em seus testes.

Finalizando

Para terminar, esse são apenas alguns dos muitos conselhos possíveis nessa área. Fiquem à vontade para usar a área de comentários do texto para expandir sobre o assunto.

Um conselho final: use seus testes como oportunidades para pensar sobre a sua aplicação. Se você se vê em uma situação em que testar está se convertendo em algo progressivamente mais complicado, alguma coisa está errada na forma como você desenhou seu código. Pare, pense sobre o assunto, e refatore. Seu código e seu tempo agradecem.

A grande divisão

O problema é que a maioria das pessoas que pratica uma variante ou outra nunca leu a literatura sobre o assunto e por causa disso há uma falta de formalização sobre o assunto. Muito do que se vê escrito hoje tanto sobre TDD ou BDD é escrito da forma que aquela pessoa em particular pratica o assunto e não como o conceito foi sendo desenvolvido ao longo das anos.

Tome, por exemplo, TDD como popuralizado originalmente por Kent Beck no contexto de Extreme Programming. Existe uma granularidade envolvida no crescimento do código que pode ser descrita como orgânica.

Design ou Development?

Uma das coisas que sempre me ajudou a enxergar o modo apropriado de construir uma aplicação a partir de testes foi pensar no D final de TDD ou BDD não como desenvolvimento, mas como design.

Voltando ao tema de granularidade, se você fizer uma experimento e acompanhar dezenas de pessoas que “praticam” TDD ou BDD, o mais provável é que você perceba que os testes estão sendo escritos como uma forma de cobrir o código e não como uma forma de pensar no código em si. Um teste é escrito que demonstra um certo caso de uso da classe ou método em questão e o código para aquele trecho é então escrito.

É muito comum, dentro da prática descrita acima, que vários testes seja escritos em seqüência e o código da classe ou método inteiro seja depois implementado. Voltando ao modo como Kent Beck explicou o processo originalmente, nada por estar mais longe da realidade.

De fato, nos seus exemplos concretos sobre o assunto, Kent Beck compara o uso de TDD ao uso de uma lista de tarefas para a construção de código, o que força o desenvolvedor a pensar em detalhes sobre a arquitetura que está criando. Volta aqui o sentido de design e não de desenvolvimento puro.

Chega-se então ao ponto de que cada teste é pensado como uma forma de evoluir a arquitetura do código e pensar em como aquela classe ou método existe dentro do contexto mais generalizado da aplicação. Não é surpreendente que quando isso é feito, coberturas de 100% são factíveis, métodos ou funções não possuem mais do que algumas poucas linhas fazendo exatamente e o que deve fazer e não mais e uma delegação efetiva de responsabilidades acontece.

TDD versus BDD

Chega-se então ao ponto central da conversa? Qual é a diferença principal entre TDD e BDD? No ponto mais básico da cadeia, a resposta é: nenhuma.

Tanto TDD quando BDD são formas de se pensar em testes partindo de premissas ligeiramente diferentes mas chegando ao mesmo resultado prático. Sendo feitas de maneira apropriada, o resultado final dentro das necessidades acima (cobertura, delegação, arquitetura) é o mesmo e a conversação que deve acontecer no desenvolvimento ocorre naturalmente.

Apesar disso, há uma diferença histórica que está evoluindo com o tempo e que, em última instância, está se convertendo no foco de debate entre os dois campos. Essa diferença foi inicialmente expressa por Dan North (responsável pelo desenvolvimento do RBehave, que mais tarde se tornaria a base do Story Runner do RSpec) e depois elaborada por David Chelimsky.

Esse posicionamento coloca BDD não como uma oposição direta a TDD em termos práticas, mas como uma corrente filosófica que engloba TDD e expande o discurso para incluir elementos que vão além do metodológico e já começam a cair no processual.

Um exemplo claro disso é a ascensão de frameworks orientados a estórias (testes de aceitação de usuários) como o Cucumber. Esses esforços representam a graduação de BDD não somente com uma forma de fazer testes mas como um processo de pensar e executar testes ao longo de toda a gama de necessidades de uma aplicação (de unitários e visuais).

Essa conversa é a parte mais importante do BDD e, no caso do Rails e Ruby, o RSpec representa apenas uma faceta de tudo o que vem sendo pensado pela comunidade. Eventualmente, como Chelimsky coloca, TDD será um parte de algo maior que será chamado de BDD.

Finalizando

A confusão experimentada atualmente é mais resultado da conversação acima do que da diferença real entre os frameworks. Ainda citando Chelimsky, quando BDD era somente sobre testes unitários, não havia diferença nenhum entre TDD e BDD. Ambos eram e são sobre a melhor forma de testar uma aplicação e nada mais do que isso.

Para dar um exemplo, atualmente eu tenho preferido a combinação Test/Unit + Shoulda + RR ao invés do meu usual RSpec. Gosto da leveza dos anteriores em relação ao último quando os testes se tornam mais envolvidos. Mas isso representa apenas dores de crescimento do RSpec. É bem possível que quando este último estiver mais estabilizado, lidando mais com a magia negra que ele precisa para sua sintaxe, eu mude novamente de prática.

De uma forma geral, então, escolha o frameworks que melhor lhe convier. Desde que a forma como você faz testes esteja correta, o resultado final estará correto também.

Isso não quer dizer, é claro, que ele não seja muito vulnerável. Como Taplin mesmo aponta, o governo está tendo que queimar milhões de reais para manter a moeda em um nível de valorização razoável. Da mesma forma, a queda da bolsa brasileira é uma das mais acentuadas.

Mesmo assim, é interessante ver que, na situação atual, o Brasil está em uma posição bem diferente da imaginada há alguns anos atrás. Ninguém apostaria suas fichas nem de longe em um Brasil com um economia estável e um poder de influência razoável no mercado global. Se nem tudo são flores, pelo menos não há um pânica generalizado em um momento que outros já estão em plena fuga.

Agora, se ao menos houvesse um jeito de exilar todos especuladores…

No geral, foi uma experiência bem positiva. Para um tutorial que começou como material para um curso, a quantidade de pessoas interessadas foi surpreendente. Mesmo na época, havia uma carência enorme de informações sobre o assunto. Coincidentemente, o primeiro livro de Rails no Brasil também foi lançado na mesma época. Acho muito legal, inclusive, que pessoas que hoje são extremamente ativas na comunidade tenham tido contato inicial com Rails através do tutorial.

Bem, esse monte de reminiscências é para anunciar aos leitores regulares que possam eventualmente desejar aprender Rails e aos visitantes que volta e meia chegam aqui perguntando sobre o assunto e topando com um tutorial desatualizado que uma nova versão está disponível.

No melhor espírito da GFDL, Cássio Souza atualizou o tutorial para Rails 2.1, modificando o material antigo, removendo as partes ultrapassadas e acrescentando muito material novo em um novo tutorial que reflete mais precisamente a versão atual do Rails (de 1.2 para 2.1). O material também é acompanhando de screencast que explica mais detalhes práticos sobre o assunto.

Fica aí a dica para quem quer aprender sobre Rails de maneira prática. E que venha os downloads.

De um lado, especialistas justificam sua escolha em termos de melhores salários, pouco rotatividade, maior reconhecimento. Do outro lado, os generalistas justificam com maior estabilidade, menos rotina, maior amplitude de oportunidade. Sempre há uma certa tensão entre as duas versões do profissional de TI e como qualquer dicotomia, geralmente a verdade é uma coisa inteiramente diferente.

No tempo que eu tenho de carreira, o que eu observo é que a dicotomia é inteiramente falsa. Se existe o bom profissional, não há como o mesmo ser especialista ou generalista. Em um área como a nossa, onde a velocidade de transformação é enorme, medida em meses e semanas ao invés de décadas e anos, qualquer coisa que não seja a fusão dos dois conceitos é simplesmente impensável.

Ironicamente, algumas das raízes dessa separação refletem, ou talvez até tenham sua origem, na antiga disputa entre consultores e empreendedores–centrada, por sua vez, na igualmente inválida dicotomia entre engenheiros e artesãos. Como a maioria das comparações feitas para explicar o desenvolvimento de software, as analogias passam longe de explicar a realidade.

Recentemente, a popularização de frameworks e linguagens fora do mainstream como Rails/Ruby e Django/Python permitiu uma rara observação de como qualquer separação explícita geralmente é de aplicação limitada.

Um caso usual é tomar um profissional que trabalha com uma dessas tecnologias, que está tentando sair do comum em seu trabalho, seja como forma de criar uma nova carreira ou mudar sua empresa para obter uma carreira mais interessante, e por via dessa necessidade forja uma aliança entre áreas díspares como gerência, design, usabilidade, programação e outras (às vezes acumulando todas essas funções sobre si mesmo) e usar isso como exemplo de que o generalizado é melhor do que o especializado.

O mesmo erro é tomar uma disciplina como medicina e usar para ilustrar a outra proposição. Enquanto o exemplo do parágrafo anterior é um erro ao assumir que o mesmo é um exemplo de arte, o segundo é um erro em assumir que “engenharia” é uma metáfora inteiramente válida para o desenvolvimento de software.

A realidade é que, como em qualquer área, o nosso grau de proficiência é inteiramente dependente do âmbito do que estamos fazendo no momento e das circunstâncias transitórias em que esse trabalho se exprime. A especialização, nesse sentido, vem mais como força da acumulação de experiência do que de uma escolha explícita.

Um desenvolvedor é um engenheiro? Sim. É um artista? Também. Por extensão, a mesma pergunta pode ser feita para a dicotomia inicial. É um generalista? Sim. É um especialista? Também.

Isso é o que Dave Thomas fala quando explica sobre o Dreyfus model. Você vai de um lado do espectro ao outro e às vezes está em vários pontos em várias áreas. Quando isso é considerado, a dicotomia cai imediatamente por terra.

Em última instância, como a maioria das preocupações similares, o único resultado da eterna discussão é o gasto de tempo e calorias que poderiam ser postos para melhor uso em projetos mais interessantes. Na próxima vez que alguém quiser discutir isso com você, dê de ombros e ignore. Você não estará perdendo nada de valor para sua carreira futura.

Atualização: A propósito, acabaram de chamar a minha atenção que o Carlos Brando e o Fábio Akita fazem essencialmente o mesmo ponto no Rails Podcast Brasil #34. Desnecessário dizer, concordo.

O que nenhum desse milhões de textos diz é que a verdade é bem mais simples do que parece. Neste pequeno texto, chame de cartilha se quiser, apresento o método mais efetivo, mais seguro e mais recompensador de se erguer aos pináculos da sua blogosfera de escolha. E isso tudo sem o inconveniente de parecer um plagiador.

O método descrito abaixo compreende a criação de um formato específico de artigo, necessariamente longo–o que significa que a técnica só vai funcionar para aqueles com paciência de escrever algo além das médias três linhas que compõem o usual texto de um blog–dispensado aos leitores em doses ocasionais, duas a três vezes por semana. Esse texto possui seções específicas que agora descrevo:

Parte I - Do assunto

O primeiro passo é escolher um tema que esteja em voga. Atualmente, por exemplo, pode ser algo relacionado à crise econômica, Obama versus McCain, o sempre presente fluxo de start ups Web, os lançamentos de produtos de firmas Web famosas e assim por diante. Se você não consegue ter idéias, basta visitar um site de notícias Web qualquer e usar a inspiração.

Como é possível ver, escolher o assunto é muito simples. Basta reusar algo que está sendo falado ou que está no “inconsciente coletivo” da Web no momento. Você vai perceber depois de alguns artigos que não é necessário nenhum tipo de originalidade. Afinal de contas, ninguém é original.

Parte II - Do título

O título, novamente, é tão simples quando escolher o assunto. Na verdade, existem somente três tipos de títulos que levam ao estrelato. A menos que você queira variar ocasionalmente, para surpreender um ou outro leitor, você deve ser conformar a estes três padrões, que são:

• Como [alguma coisa]. Por exemplo, Como blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou Como entender as eleições americanas, ou Como ser um marketeiro eficaz.
• [N] passos para [alguma coisa]. Por exemplo, 5 passos para blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou 3 frases para entender as eleições americanas, ou 9 atitudes para ser um marketeiro eficaz.
• D[a/as/o/os] um [assunto qualquer]. Por exemplo, Dos passos para blogar efetivamente, ficar famoso e ganhar leitores sem parecer um plagiador; ou Das necessidades de entender as eleições americanas, ou Das vantagens de ser um marketeiro eficaz.

Como é possível perceber, não existe esforço nenhum em criar um título eficiente. Basta adaptar alguma frase pequena nos moldes acima e você terá um pagerank vencedor à sua espera.

Parte III - Da introdução

Depois de falar na parte fácil, é hora de falar da parte mais difícil. Como o seu professor de literatura da quinta série costumava dizer, a introdução e a conclusão são duas das partes mais importantes de um texto. Já que só sobra o desenvolvimento, acho que esses professores estavam pensando em seus alunos como blogueiros futuros.

Mas, infelizmente, tais professores estavam certos. A parte mais difícil de um texto vencedor é a introdução. E isso porque, de todo o resto, é a única que vai exigir um módico de originalidade. Se você começar a copiar na introdução, vai ser sacado rapidamente. Mas não se preocupe, como uma boa introdução não passa de dois ou três parágrafos–que podem ser curtos–o risco de errar é mínimo.

Para uma boa introdução, basta criar esses dois os três parágrafos–que podem ser duas ou três linhas na verdades, mas não se esqueça das quebras para torná-los mais convincentes–com alguma citação famoso seguida de uma declaração sobre como você vai iluminar o assunto. Varie isso a cada artigo e os leitores vão achar que você é, além de tudo, um erudito.

Parte IV - Do conteúdo, ou, da verborréia necessária

Se a introdução é complicada, o conteúdo em si é absurdamente simples. Tudo o que é necessário é uma quantidade razoável de verborréia parafraseadas, citada e puramente copiada e você está pronto para a glória.

Para acertar a mão, basta seguir os passos abaixo:

1. Primeiro, encontre um autor que tenha escrito algo que seja pertinente ao seu assunto (mesmo que apenas de leve) e que esteja em voga. Atualmente, livros como A Lógica do Cisne Negro, Blink, The Tipping Point, Freakonomics, The Long Tail, The Big Switch, Linked ou qualquer outra nessa linha de assuntos modernosos que se propõem a explicar tudo sobre tudo.

2. Livro escolhido, você precisa agora seguir um padrão bem simples: três parágrafos de paráfrase, ou seja, falando exatamente o que o autor falou em algum ponto do livro com suas palávras, e um parágrafo citando o autor do livro. Para cada conjunto desse, coloque um título parafraseado do próprio lido ou inventado na hora mesmo.

3. Para não ficar ainda mais interessante, a cada dez ou doze parágrafos, introduza alguma citação ou paráfrase de outro autor. Se leitores vão achar você ainda mais erudito pela profundidade das correlações.

E é só. Desde que o artigo seja grande, o esforço será notado. Caso você não queira se dar ao trabalho de ler um livro ou mesmo escaneá-lo em busca de citações interessantes, um artigo em uma publicação da sua área também serve. Seja a InfoQ, Wired ou The New York Times, o importante é contar a estória direito.

Parte V - Da conclusão

Finalizar, ao contrário do que o seu professor dizia, não é tão complicado. Basta criar alguma expectativa no leitor de como ter lido aquele artigo mudou a vida dele ou explicar como, de posse das informações que você passou, que você tão cuidadosamente colou em um artigo de proporções avassaladoras, vai transformar a sua compreensão de tudo o mais e torná-lo mais erudito, famoso ou eficiente. Qualquer dessas palavras ou similares em uma frase já é vencedora.

Conclusão

Como você pode ver, o processo todo é simples (embora um pouquinho trabalhoso). Mas, como já diziam os antigos, no pain, no gain. Basta seguir as instruções, gastar uns 20 ou 30 minutos coletando citações de suas obras favoritas e você terá algo original, digno de uma mestrado ou doutorado.

Para terminar, depois de postar o texto, sente-se e aguarde as dezenas de comentários congratulando você por sua elegância, erudição e compreensão do mercado. Depois de tanto trabalho, você mereceu.

P.S.: Disclaimer Eu presumo que os leitores regulares vão perceber imediatamente que o texto acima é irônico. Mas, como várias pára-quedistas podem pensar o contrário, fica aqui o disclaimer. Não vai adiantar muito, provavelmente, mas o seguro morreu de velho.