* 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

Se estiverem trabalhando com Rails e Selenium e desejam subir e derrubar o servidor automaticamente antes e despois dos testes então podem utilizar o Mongrel:

mongrel_rails start -e test -d
mongrel_rails stop

Por exemplo, eu que estou utilizando Selenium com Cucumber, tenho meu env.rb assim:

require 'spec/expectations'
require 'selenium'

# "before all"
`mongrel_rails start -e test -d`
`rake db:populate RAILS_ENV=test`
browser = Selenium::SeleniumDriver.new("localhost", 4444, "*chrome", "http://localhost", 15000)

Before do
  @browser = browser
  @browser.start
end

After do
  @browser.stop
end

# "after all"
at_exit do
  browser.close rescue nil
  `mongrel_rails stop`
end

describe User do
  should_be_authentic
end

Conversando com o Davis ele me comentou que demorou quatro minutos em criar o plugin, utilizando como base o Remarkable::Paperclip, deve ser muito fácil né?

Se você gostou do plugin, considera recomendar o Davis no Working With Rails, ai você aproveita e me recomenda também

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!

Definir uma atividade especifica no título

Numa estoria descrevemos como uma funcionalidade gera algum tipo de valor para o cliente. No título definimos essa funcionalidade brevemente e ate a estoria não estar finalizada quer dizer que a funcionalidade não poderá ser realizada. Dado que diversas funcionalidades geram diferente valor para o cliente, não e legal juntar mais de uma funcionalidade numa estoria porque a finalização de uma funcionalidade estaria dependendo da finalização de outra.

Muitas estorias tem títulos como “Gerenciar artigos” onde nos cenários definem se a funcionalidade é uma adição, remoção e edição, por exemplo. Seguindo a teoria, ate não termos finalizado as trés funcionalidades, o usuário não iria poder gerenciar artigos. Acontece que nesse exemplo o usuário se importa mais com a adição de artigos, a única funcionalidade que já foi implementada. Se ela estivesse numa estoria separada, teríamos uma nova estoria finalizada e um nova funcionalidade já poderia ser entregue para o cliente.

E importante mencionar também que estorias mais simples e pequenas são mais fáceis de estimar, pelo que estorias muito grandes com muitas funcionalidades vão adicionar uma dificuldade nesse aspecto.

Definir estados nos cenários

Se nos títulos colocamos atividades, nos cenários colocamos estados. Supondo que as pessoas que acostumavam descrever as funcionalidades nos cenários vão seguir a primeira sugestão do artigo, vão poder ficar na duvida sobre o que por aqui. Nos cenários devemos descrever como o sistema devera se comportar quando exercer a função (título da estoria) num estado definido (título do cenário). Normalmente os cenários respondem à pergunta “Que acontece se …?”.

Imaginemos que temos a funcionalidade Efetuar pagamentos com cartão de debito. Temos entendido bem o que ira gerar valor para o cliente, mas como o sistema deve se comportar? Que acontece se a conta não tem mais dinheiro disponível? Que acontece se o cartão esta bloqueado? Que acontece se a conta tem dinheiro?

Essas trés ultimas perguntas tem definido trés cenários:

• a conta tem dinheiro
• a conta não tem dinheiro
• o cartão esta bloqueado

Não definir implementações

Ao não definirmos implementações nas nossas estorias vai ser muito mais fácil manter o foco no negocio ao invés da ferramenta. Tomemos como exemplo o seguinte cenário, onde a funcionalidade é registrar produtos:

Dado que visito a pagina de novos produtos
Quando preencho o formulário de novos produtos
E faço um click no botão 'registrar'
Então o numero de produtos existentes deve ser acrescentado por um

Esse cenário esta descrevendo mais o comportamento da ferramenta que do negocio em si. O que gera valor para o cliente não é preencher um formulário e poder clicar num botão, o que gera realmente valor e o que o cliente quer é registrar um produto. Sobre a página de novos produtos, ela não e parte do negocio, é parte da implementação.

Uma coisa que acabei de perceber agora é que muitos cenários acostumam descrever a primeira ação do cliente no passo Given ou Dado. Acho que isso ocorre porque esse passo é encarregado de definir um estado inicial ou contexto e como se esta pensando na implementação, o estado inicial poderia ser considerado a primeira interação do usuário com a ferramenta.

Mas como não devemos pensar na ferramenta e sim no negocio, no passo Given devemos indicar como estão as coisas antes das atividades do negocio. O passo Given tem relação direta com o título do cenário.

Acho que o cenário de exemplo ficaria melhor assim:

Dado que o numero de produtos é 2
Quando registro um novo produto
Então o número de produtos deve ser 3

O cenário fica simples porque o que gera valor é simples: registrar um produto. Os passos Given e Then (Então) podem ficar meio óbvios e desnecessários mas eles servem para preparar o teste (Given) e verificar se o teste deu certo ou não (Then). É bom manter esses dois passos também simples porque assim nossos testes ficam do mesmo jeito.

Mais informacão

Um post que me ajudou bastante no processo de melhorar minhas estorias foi este do Dan North, pai do BDD, muito recomendado. Nesse mês também saiu na revista Mundo Java um artigo muito legal do Rodrigo Yoshima falando sobre estorias, mais informação aqui.

Qualquer duvida ou discordância comigo por favor escreve-la nos comentários, acho muito legal conhecer os diferentes pontos de vista das pessoas.

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.