Ate que todos os commits sejam aceitos no repositorio oficial, o que podem executar para ter o ambiente configurado é o seguinte:

git submodule add -b rails3 git://github.com/dcrec1/blue-ridge.git ./vendor/plugins/blue-ridge
rails g blue_ridge:skeleton
rails g blue_ridge:javascript_spec core
rake spec:javascripts

Caso não conheçam o Blue-Ridge, o Dr. Nic publicou faz um tempo um post onde explica a ferramenta e onde também publicou o video de uma palestra que ele deu no Rails Underground 2009.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

* spec/spec_helper.rb:

require File.join(File.dirname(__FILE__), '..', 'main.rb')

require 'spec'
require 'rack/test'

Spec::Runner.configure do |conf|
  conf.include Rack::Test::Methods
end

def app
  Sinatra::Application
end

* spec/main_spec.rb:

require 'spec_helper'

describe Sinatra::Application do
  context "responding to GET /" do
    it "should return status code 200"
      get '/'
      last_response.code.should == 200
    end
  end
end

* Rakefile:

...
require 'spec/rake/spectask'

desc "Run all specs"
Spec::Rake::SpecTask.new do |t|
  t.spec_opts = %w(--format specdoc --color)
end

o RSpec::VRaptor é totalmente compatível com o novo VRaptor 2.6 Nice URLs!

O VRaptor 2.6 vem com um plugin chamado Nice URLs que permite definir rotas para à aplicação num arquivo, estilo Rails.

Mas não só isso, a ultima versão do RSpec::VRaptor adicionou uns matchers muito legais, segue um exemplo do que é possível realizar agora:

describe CarController do

  context "na action action1" do

    before :all do
      get "/car/action1", :cookies => {'key' => 'value'}
    end

    it "deve ter um header com a data da resposta" do
      @response.headers['Date'].should_not be_nil
    end

    it "não deve ter uma view de resposta" do
      @request.should be_viewless
    end

  end

  context "na action action2" do

    it "deve renderizar o arquivo action2.erb" do
      get "/car/action2"
      @request.should render("car/action2.erb")
    end

    it "deve redirecionar para a home se o usuário estiver logado" do
      get "/car/action2", :session => {'logged' => true}
      @response.should redirect_to("user/home")
    end

  end

end

Como podem ver, agora não só podemos injetar cookies no nossos requests, também podemos verificar os headers de resposta, validar se a requisição é viewless (método com anotação @Viewless), se vai ser renderizado um arquivo x ou se a resposta redireciona para algum outro recurso.

Os que me seguem no Twitter devem estar sabendo que nos últimos dias esteve trabalhando num projeto em Java porém utilizando RSpec para testar ele. Se você ainda testa código feito em Java utilizando Java, te recomendo sair dessa vida, gasta um dia ou o tempo que for necessário para poder criar testes utilizando RSpec e se feliz criando testes de qualidade.

No projeto mencionado, a maioria dos desenvolvedores se sentia confortável utilizando Maven pelo que teve que me adequar a essa ferramenta que eu tanto gosto (ironia mode on) e averiguar se existia algo que vinculasse ela ao RSpec.

Foi assim que achei esse post onde Bob apresenta o plugin rspec-maven-plugin que permite executar os testes criados en RSpec ao executar o target test do Maven, todo o que eu queria.

Configurei o plugin no meu pom.xml, executei a target test e… não funcionou. Como todo problema é também algo bom porque oferece a oportunidade de fazer algo legal, decidi realizar um fork do projeto e corrigir ele.

O plugin

Como o plugin não esta no repositório oficial, para instalar o plugin rspec-maven-plugin deve ser executado:

git clone git://github.com/dcrec1/rspec-maven-plugin.git
cd rspec-maven-plugin
mvn install

Caso não tenham o Git instalado, podem baixar as fontes de aqui.

Uma vez no repositório local, podem configurar o plugin adicionando o seguinte ao pom.xml:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rspec-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>spec</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Depois disto, o único pre-requisito para executar o plugin é setar a variável de ambiente JRUBY_HOME.

Ao executar o target test, o Maven ira executar os testes dentro da pasta spec.

Obrigado JRuby, happy testing!

Num dos comentários foi indicado este post do blog dos caras da thoughtbot onde entre outras práticas, criticam a que acabei de mencionar no paragrafo anterior.

Uma boa crítica vem sempre com argumentos e nesse casso achei os argumentos fracos, vamos ver por que.

6 registros criados

O autor do post mostra um código feito em Shoulda onde antes de cada teste cria um registro na base de dados é menciona que o padrão é ruim porque para seguir ele teve que criar seis registros na base. Quem mandou criar um registro antes de cada teste? Se analisam meu post anterior, vão poder apreciar que no exemplo dado eu escrevi:

antes :todos do
  envio_mail = EnvioEmail.new("morena@opensource.com")
end

e não:

antes :cada_um do
  envio_mail = EnvioEmail.new("morena@opensource.com")
end

Shoulda não tem como definir um bloco que vai ser executado antes de tudo? Caso seja assim, problema do Shoulda, não é problema do padrão. Independente de escolher o padrão o não, os testes tem que ser inteligentes.

TDD deve ter ritmo

O autor, no mesmo código, mostra uns testes que são realizados numa linha (macros) e outros que são realizados em trés linhas e argumenta que o padrão é ruim porque o código não tem ritmo é TDD deve ter ritmo. Alguém acha que isto tem algum sentido? O padrão não exige que você tenha testes de uma linha e outros de três. Isso não tem nada a ver com o padrão, eu poderia ter o mesmo comportamento sem seguir o padrão, por exemplo:

should_respond_with_xml_for 'user'

should 'include the user id and user name' do
  assert_select 'id', @user.id.to_s
  assert_select 'name', @user.name
end

E agora, vai dizer que o Shoulda é ruim porque criei um código que considero que não tem ritmo? São então os macros ruins porque eles tiram o ritmo do código?

Os nomes dos testes ficam ruins

Não sei se entendi direito esse argumento mas me parece que o autor esta reclamando de que com mas testes ele é obrigado a criar nomes muito específicos. Supondo que estou certo no meu entendimento, a intenção do padrão é justamente essa, criar testes que especifiquem o que estão testando e o que o código deve fazer. Quando executamos os testes acho melhor receber:

a GET to /users/:id.xml should respond with success
a GET to /users/:id.xml should render template show
a GET to /users/:id.xml should find the correct User
a GET to /users/:id.xml should respond with xml for user
a GET to /users/:id.xml should include the user id
a GET to /users/:id.xml should include the user name

que

user show xml

Utilizei “user show xml” porque o segundo código que o autor mostra é um único teste com nome “test_user_show_xml”. “user show xml” não nos diz nada sobre o sistema. Se eu leio esse teste eu vou entender que o usuário deve mostrar um xml. O primeiro caso nos diz bastante sobre o sistema, é uma especificação executável.

WTF

Também não se se entendi direito essa de aqui mas me parece que o argumento diz que se queremos realizar testes curtos por que não utilizamos então o Test::Unit e não RSpec e Shoulda com seus describe, it, should e context que nos obrigam a utilizar trés linhas no mínimo. Que tem a ver isso com o padrão, ele em nenhum momento fala de deixar o código menor. Alias, acho que esse argumento é ate à favor do padrão. Tem gente que diz que não segue o padrão porque gosta de escrever menos código. Beleza, vamos utilizar Test:Unit então.

Finalmente o autor do post mostra um código realizado encima do Test::Unit com todos os assert dentro de um teste, utilizando o nome mencionado anteriormente. Eu acho esse teste ruim porque não especifica nada e para entender o que ele testa é necessário ler o código.

Para terminar, no post é mencionado que o padrão um assert por teste é uma solução a um problema que não existe, mas o problema existe sim, e ele é o seguinte:

Escrever documentação não executável de um código é muito custoso porque a cada mudança no código deve ser mudada também a documentação e isso gera trabalho em dobro. Além do trabalho em dobro, a documentação não executável não garante que o código faz o que esta escrito no papel. A solução a isto é criar documentação executável e documentação executável quer dizer testes que especificam e para criar testes que especificam a solução mais fácil é criar um assert por teste.

Antes de justificar por que eu acho que o padrão deve ser seguido, vou dizer que especificação e teste são para mim duas coisas diferentes, mas são duas coisas que se complementam. Nada melhor para me explicar que com exemplos:

it "should find customers by a given name" do
  ...
end

test "customers are found by a given name" do
  ...
end

public void testCustomersAreFoundByAGivenName() {
  ...
}

Nos três blocos acima, em todos os casos temos um requisito ou especificação do nosso sistema (”os clientes devem ser encontrados dado um nome”) e um código ou teste (”…”) que verifica que esse requisito/especificação esta sendo satisfeito. Podemos chamar o conjunto inteiro de teste mesmo, mas é importante não esquecer de que nele devemos ter uma especificação.

Somente como anedota, tem muitas vezes que baixei o código fonte de algum framework ou api somante para ver os testes e poder saber o que o código pode e não pode fazer. Os testes podem e devem ser muito informativos.

Mas por que estou falando isso? Estou falando isso porque esse comportamento desejado é muito fácil de se alcançar se você seguir o padrão um assert/expectativa por teste. Seguindo esse padrão você vai ter mais blocos de testes, então você vai ter que nomear mais vezes o que o teste ira validar e para não repetir nomes automaticamente você terá que ser mais específico, o que ira criar uma especificação mais detalhada.

Do meu lado esta a ultima Java Magazine, vou pegar o primeiro teste que encontrar na revista como exemplo:

test "enviar relatorio" do
  envio_mail = EnvioEmail.new("morena@opensource.com")
  assert_true envio_email.enviar
  assert_equals envio_mail.texto_mensagem, "Testes executados com sucesso"
  assert_equals envio_mail.get_titulo, "Resultado testes"

  esperado = Arquivo.new("xpto.zip")
  enviado = envio_email.arquivo_mensagem
  assert_equals esperado, enviado
end

Antes de aplicar o padrão, qual é o problema com o teste anterior? Imaginemos que estamos executando nosso teste y no terminal aparece que o teste “enviar relatório” falhou. Se eu vejo isso vou pensar que o relatório não foi enviado, mas ele foi! O teste pode ter falhado porque no título se esperava “Resultado testes” e se obteve “Resultado testes.”, com um ponto a mais. O teste não esta somente testando se o relatório foi enviado, esta também testando se ele foi enviado com o título certo, só que o nome não diz isso. Se vendo os testes, nenhum diz que o relatório deve ser enviado com o título certo, posso considera lo como um requisito? Se é um requisito, onde esta escrito? Tenho que ficar analisando dentro dos testes para saber o que o sistema deve ou não fazer? Se não é um requisito, porque esta invalidando o teste?

Aplicando o padrão mencionado no exemplo ele ficaria mais ou menos assim:

antes :todos do
  envio_mail = EnvioEmail.new("morena@opensource.com")
end

test "relatório é enviado" do
  assert_true envio_email.enviar
end

test "relatório é enviado com o texto certo" do
  assert_equals envio_mail.texto_mensagem, "Testes executados com sucesso"
end

test "relatório é enviado com o título certo" do
  assert_equals envio_mail.get_titulo, "Resultado testes"
end

test "relatório é enviado com o arquivo certo" do
  esperado = Arquivo.new("xpto.zip")
  enviado = envio_email.arquivo_mensagem
  assert_equals esperado, enviado
end

Não ficou bem melhor?

Agora, supondo que o problema não foi corregido, ao executar os testes vamos receber que o requisito “relatório é enviado com o título certo” não esta sendo satisfeito, mas ao menos sabemos que isso é um requisito e rapidamente podemos identificar que parte do processo “enviar relatório” não esta correto.

Pensando agilmente, esse requisito que não passou pode não representar muito valor para o cliente. O maior valor para o cliente pode estar em enviar o email mesmo e o teste diz que o email esta sendo enviado, pelo que o cliente poderia aceitar o software e não esperar ate que os outros requisitos que não geram tanto valor sejam satisfeitos.

Mais informação sobre o padrão pode ser encontrado aqui nesse post do Jay Fields. Foi o post que me convenceu de seguir esse padrão e desde ai o venho utilizando.