Integração Sinatra, Cucumber e Webrat

Sempre que consigo algum tempo tento escrever alguma coisa no blog e desta vez quero mostrar como é fácil o desenvolvimento em BDD no Sinatra usando Cucumber e Webrat. Para quem numca ouviu falar nesses caras vamos as apresentações. 🙂

Quem é esse Sinatra?
Para quem não saber Sinatra é uma linguagem de domínio específico (DSL – Domain Specific Language) para a criação rápida de aplicações web escritas em ruby. Ele mantém uma característica mínima definida, deixando livre o desenvolvedor para utilizar as ferramentas que melhor lhe servir em sua aplicação.

BDD? Cucumber?
BDD ou Behavior Driven Development(Desenvolvimento Guiado por Comportamento) é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software. O foco em BDD é a linguagem e interações usadas no processo de desenvolvimento de software.

O Cucumber foi criado para permitir que você execute a documentação de funcionalidades de uma aplicação, escritas em texto puro (também conhecidas como “estórias”). Com o Cucumber, isto é uma especificação executável que você pode discutir com seu cliente e então usá-la para verificar o comportamento correto dos testes. Por trás dos bastidores, você faz isto funcionar criando “steps”, que são expressões regulares que executam código em Ruby.

Webrat
Webrat é uma ferramenta fantástica que permite escrever rapidamente testes de aceitação expressivos e robustos para uma aplicação web Ruby. Ele nos fornece entre outras coisas:

  • Simulador de browser de alto nível;
  • Suporta vários frameworks web Ruby;
  • Suporta os mais populares frameworks de teste;
  • Fornece uma API para verificar o HTML gerado usando CSS, XPath, etc.

Depois de feita as devidas apresentações vamos colocar a mão na massa. O primeiro passo é criar o diretório de nosso projeto.

1
2
$ mkdir sinatra-cucumber
$ cd sinatra-cucumber

Vamos acessar a pasta do projeto que acabamos de criar e executar os comandos abaixo para criar a pasta onde iremos definir nossas features.

1
2
$ mkdir features
$ touch features/ola.feature

Obs.: Para quem não conhece o comando touch apenas criou um arquivo vazio.

No arquivo ola.feature escreva o seguinte código:

1
2
3
4
5
6
7
8
9
# language: pt
Funcionalidade: Ver páginas
  Como um usuário qualquer
  Eu quero acessar as páginas do sistema
  Para ter acesso a seu conteúdo
 
  Cenário: Página principal
    Dado que acabei de acessar o sistema
    Então Eu devo ver o texto "Olá, pessoal!"

Vamos executar o cucumber e ver o que acontece. 🙂

1
$ cucumber features/ola.feature

Como era de esperar o teste não passou. Vamos em seguida criar os testes para nossa funcionalidade mais antes iremos criar uma tarefa rake para otimizar a chamada do Cucumber.

1
$ touch Rakefile

O código para nossa tarefa rake que será executada com o comando “rake features” é o seguinte:

1
2
3
4
5
6
require 'rubygems'
require 'cucumber/rake/task'
 
Cucumber::Rake::Task.new(:features) do |t|
  t.cucumber_opts = '--format pretty'
end

Agora sim podemos continuar.

1
2
$ mkdir features/step_definitions
$ touch features/step_definitions/ola_steps.rb

No arquivo ola_steps.rb teremos o seguinte código:

1
2
3
4
5
6
7
Dado /^que acabei de acessar o sistema$/ do
  visit("/")
end
 
Entao /^Eu devo ver o texto "(.+)"$/ do |texto|
  response_body.should =~ Regexp.new(Regexp.escape(texto))
end

Estes dois passos simples fazem uma solicitação a url do nosso aplicativo pelo Webrat e verifica se a resposta contém o texto que estamos procurando.

Abaixo segue as configurações que fazem a integração realmente acontecer. Vamos configurar o ambiente do Cucumber para usar o Webrat.

1
2
$ mkdir features/support
$ touch features/support/env.rb

O conteúdo do arquivo env.rb deve ser o seguinte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
require 'spec/expectations'
require 'rack/test'
require 'webrat'
 
Webrat.configure do |config|
  config.mode = :rack
end
 
class MyWorld
  include Rack::Test::Methods
  include Webrat::Methods
  include Webrat::Matchers
 
  Webrat::Methods.delegate_to_session :response_code, :response_body
 
  def app
    Sinatra::Application
  end
end
 
World do
  MyWorld.new
end
 
require File.dirname(__FILE__) + '/../../ola'

Agora que temos nosso cenário montado podemos escrever nossa aplicação web com essas simples linhas abaixo:

1
$ touch ola.rb
1
2
3
4
5
6
require 'rubygems'
require 'sinatra'
 
get '/' do
  "Olá, pessoal!"
end

Agora vamos executar mais uma vez o Cucumber e ver os testes passando para ficarmos felizes. 🙂

1
$ rake features

Bom pessoal, o objetivo foi cumprido e espero que tenha ficado claro como é fácil desenvolver em Sinatra usando BDD com Cucumber e Webrat. Sei que o exemplo foi bem simples e abaixo segue o código fonte do projeto e alguma referências para você conhecer mais do assunto.

Código fonte
http://github.com/igocoelho/sinatra-cucumber

Conheça mais
Livro de Sinatra em Português
http://sinatra.tailorfontela.com.br/

Aplicação simples com Sinatra
http://pomoti.com/aplicacao-simples-com-sinatra

BDD com Cucumber, Selenium e Rails
http://www.slideshare.net/cmilfont/bdd-com-cucumber-selenium-e-rails

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte I
http://jefferson.eti.br/?p=96

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte II
http://jefferson.eti.br/?p=105

Introducão ao BDD com Cucumber, RSpec, Webrat e Selenium – Parte III
http://jefferson.eti.br/?p=139

Screencast Ruby on Rails: Introdução a RSpec e Cucumber
http://vimeo.com/7108280

Be Sociable, Share!

4 comentários em “Integração Sinatra, Cucumber e Webrat”

  1. Caracas Igo, muito bom teu post.

    Acabei de executar o bicho e tá tudo verde agora :p

    Mas pra funfar no meu linux, não sei porque, tive que retirar os acentos do arquivo ‘ola.feature’. Também tive que mudar na 1ª linha do ‘env.rb’ para ‘rspec/expectations’

    Valeu!

  2. Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável ( PO ) por criar as estórias (ítens do backlog ) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *