Behaviour-Driven
Developement com Ruby
Técnicas, ferramentas e experiências.
Jony dos Santos Kostetzer

Agenda
Definições
Por que escrever testes?
TDD e BDD
BDD
RSpec - explicações e live coding
Cucumber - explicações e live coding

Desenvolvimento orientado
por testes
Em linhas gerais: Testar antes. Codificar depois.
“Como eu gostaria que minha aplicação se
comportasse?”
Origem: eXtremme Programming

O Ciclo TDD
red-green-refactor
Red
Refactor Green

Vantagens
1. Testando primeiro, você sabe exatamente o que seu
sofware precisa fazer.
2. Foco: Escrever o código mais simples que resolve o
problema.
3. Saber quando parar: Teste define quando se atinge o
“suficiente”.
4. Código mais limpo e organizado.

Vantagens
5. Identificar o mais cedo possível problemas de
regressão.
6. Segurança e refactoring sem medo.
7. Satisfação!

MANUTENABILIDADE!

Manutenabilidade?
Quão fácil é modificar o software.
Testes são fundamentais neste quesito - considerar o
futuro.
Codigo sem testes = código legado.
Funciona? Sorte!
Além de tudo: seu código, sua carreira!

Bons programadores
conseguem resolver um
problema proposto de alguma
forma.

Programadores excepcionais os
resolvem de forma sustentável.

BDD - Behaviour-Driven
Development
TDD + Novo Vocabulário + Novo ponto de vista
Ferramenta de design.
Nova abordagem: Foco em especificações de
comportamento e não nos testes de verificação.
Testes são o meio. Ou seja, especificar comportamento
utilizando testes.
Escrever software que importa!
Documentação executável
Clareza do código - comportamento

Testes em Ruby
Diversos frameworks.
Melhor x pior: Apenas escolha o que melhor lhe convir!
test/unit
miniunit
Shoulda
Micronaut
test-spec
RSpec
Cucumber

RSpec
DSL (Domain-Specific Language) para descrever
comportamento de objetos.
Expressividade
Legibilidade
Similar a estar falando com um cliente.

BDD - Novo vocabulário
test/unit rspec
should /
Asserções Expectativas
should_not
Método de Exemplo de
it()
teste código
Caso de Grupo de
describe()
teste exemplos

Terminologias
test/unit rspec
class SomeClassTest < describe SomeClass
Test::Unit::TestCase
it "should do something
def test_something
descriptive"
def setup before(:each)
def teardown after(:each)
assert_equal 4, array.length array.length.should == 4

Grupo de exemplos
(Example group)
describe Client do ... end
describe “A bank transaction” do ... end
describe Document, “being shared” do ... end

Exemplos de código (code
examples)
it “should require a valid username” do ... end
it “should not charge a user when he has sufficient
credits for the payment” do ... end
it “should not retrieve expired documents” do ... end

Expectativas (Expectations)
“ “.should be_blank
user.birthday.should == Date.today
client.active?.should be_false
client.should_not be_active
message.should match(/on Sunday/)
team.should have(11).players

Integrando
example groups + code examples

Integrando
example groups + code examples

Integrando
example groups + code examples + contexts

Code examples

Matchers pré-existentes
Igualdade
===, ==, eql, equal
Texto
should match(/regex/), =~
Array
should include, length.should, have(3).items

Matchers
o.should be_closed -> o.closed?.should be_true
o.should be_an_instance_of(String) -> o.instance_of?(String).should
be_true
o.should have_key(:id) -> o.has_key?(:id).should be_true
o.should have(5).characters -> o.characteres.length.should == 5
o.should have_at_least(12).rooms -> o.rooms.length.should >= 12
o.should be <= 7

Before/After
Antes de cada exemplo:
before(:each)
after(:each)
Antes de cada grupo de exemplos:
before(:all)
after(:all)

Outros idiomas
lambda { #codigo }.should change(algo) - (by, from, to)
lambda { #codigo }.should raise_error
lambda { #codigo }.should throw_symbol

Live coding
RSpec
http://github.com/jonysk/rsrails_rspec

Cucumber
Ferramenta para descrever comportamento a partir da
camada superior
No Rails: das views para os models. Substituem os
Testes de Integração
Foco na interface e depois camadas inferiores
(Outside-in)
O que o usuário espera? - Colaboração entre
stakeholders e desenvolvedores para especificar.
Testes de aceitação

E por que não começar nos
models? (Inside-out)
Construir o que você precisa ao invés do que você
acha que precisa.
Descoberta gradual do que precisa ser implementado
em baixo nível.

Relação Cucumber e RSpec
Cucumber: descrever o comportamento da aplicação.
“Make sure you’re writing the right code”
RSpec: descrever o comportamento dos objetos
“Make sure you’re writing the code right”
Red-green-refactor permanece:
Inicia no ciclo externo (Cucumber)
Termina no ciclo interno (RSpec)

Instalação
RSpec
gem install rspec rspec-rails
Para utilizar com Rails:
Dentro do projeto: script/generate rspec
Cucumber + webrat
gem install cucumber webrat
Para utilizar com Rails:
Dentro do projeto: script/generate cucumber

Cucumber features
Título / Narrativa / Cenários

Exemplo de feature

Internacionalização!

Implementando dos passos

Cucumber + webrat
Simulação de um browser
Comandos de integração intuitivos:
fill_in “campo”, :with => “valor”
visit “/pagina”
check “campo”
click_button “campo”

Matchers principais
should contain(‘text’)
should have_selector(‘#menu ul li.selected”, :content
=> “Dashboard”)
CSS3
should have_xpath(‘//node[@prop=”value”]’)

Implementando dos passos

Live coding
Cucumber
http://github.com/jonysk/rsrails_cucumber

Webrat + Selenium
gem install selenium-client
Habilitando Selenium no env.rb:
Webrat.configure do |config|
config.mode = :selenium
end
Desabilitar fixtures transacionais:
# Cucumber::Rails.use_transactional_fixtures

Outros tópicos
Integração continua (Integrity, CruiseControl.rb)
Ferramentas: autotest, rcov, heckle, etc
Macros: muito atenção.

Obrigado!
twitter: @jonysk
jonysk.net
jony@jonysk.net