Jony dos Santos Kostetzer

Neste dia 29 de agosto tivemos o primeiro evento especificamente de Rails aqui no Rio Grande do Sul, que foi muito bom por sinal! Parabenizo o pessoal da Softa por tomar frente na organização e promover o evento.

Disponibilizo abaixo os slides da minha palestra de Behaviour-Driven Development e os projetos no github, como havia prometido.

Espero que tenham gostado!

• Slides
• Live coding RSpec
• Live coding Cucumber

Tenho visto diversas pessoas falando do Shoulda, e algumas que já sentiram o gosto do RSpec e depois também gostaram do Shoulda. Até aí sem problemas. Agora, ao passo que surgem comparações entre RSpec e Shoulda, um sinal amarelo deveria aparecer por aí e deixar algumas coisas bem claras. E este é o objetivo do post.

Primeiro ponto

Em primeiro lugar, a diferença fundamental é: RSpec é totalmente focado no teste de comportamento (Behaviour). Esse é o seu objetivo e a orientação de sua sintaxe. Ok, é possível sim fazer testes no estilo unit/test com RSpec, mas obviamente, não é a intenção ao usá-lo. É como uma implicação na lógica clássica: vou usar RSpec, logo (deveria) me focar em testar comportamento. E, numa implicação, o inverso não é necessariamente verdadeiro.

Resumindo: RSpec é focado em testar comportamento (Behaviour Driven Development). Shoulda não é focado em testar comportamento (Test Driven Development sem o “behaviour” na história), mas tem a intenção de melhorar o test/unit com helpers, macros e contextos. É um açucar sintático que torna os test/unit mais, digamos, pragmáticos e também documentados.

Dito isso, deve-se ter muito cuidado ao compará-los porque são ABORDAGENS e VISÕES diferentes, embora o objetivo de testar seja o mesmo.

Podemos comparar apenas da seguinte forma: Eu gosto mais de RSpec, ou eu gosto mais de Shoulda. Ponto. Qualquer comparação dizendo “este é melhor”, ou “este é pior” deve ser evitada e levar essa diferença fundamental em consideração: “Eu gosto de testar comportamento com o RSpec” ou “Eu prefiro testar no modelo test/unit com Shoulda” são argumentos válidos e não depreciativos entre ambos.

Segundo ponto

Agora, quando eu vejo alguém falando que faz “BDD com Shoulda”, isso me preocupa um pouco. Eu me pergunto: “Será mesmo?”. Confesso, sou um pouco purista no que tange a testar comportamento e estou sempre procurando uma melhor forma de fazê-lo. E já vi opiniões semelhantes por aí.
É possível fazer BDD com Shoulda? Sim, mas de fato não é a tendência ao usar o Shoulda. Vejamos porque.

Suponhamos a seguinte linha, retirada da documentacao do Shoulda:

class Article < ActiveRecord::Base {
  named_scope :visible, :conditions => {:visible => true}
}

E o teste para ela com Shoulda:

should_have_named_scope :visible, :conditions => {:visible => true}

Então eu pergunto: testei comportamento ou garanti que existe aquela linha de código no meu Model? Naturalmente, a segunda opção. Não que isso esteja errado, pelo contrário, seu teste tem 100% de cobertura.

Mas, e se minha lógica estiver errada? Digamos que você esqueceu que ao chamar Article.visible não deveria incluir os itens que não foram publicados ainda. Ou seja, você esqueceu uma condição que deveria fazer parte da regra. Mas você tem o teste, então (teoricamente) sua mente está livre do medo de ter errado.

É nesse ponto que entra a idéia de testar comportamento. É mais provável que você descubra esse problema se pensou anteriormente no comportamento que sua busca deveria ter. Note, eu disse que é mais provável, não é garantido que você perceberia isso imediatamente.

OK, e como eu testo o comportamento neste caso?

Estamos lidando com uma busca. Logo, vamos testar o comportamento desta busca simulando-a com exemplos (sintaxe abaixo é RSpec):

describe Article, "being displayed on the website" do
  it "should display only visible entries" do
    visible = Article.create(:name => "Art1", :visible => true, :published_at => Time.now)
    hidden = Article.create(:name => "Art2", :visible => false, :published_at => Time.now)
    visible_not_published = Article.create(:name => "Art3", :visible => true, :published_at => nil)
 
    Article.visible.should be_eql([visible])
  end
end

Nota: Num contexto real, estou usando o plugin factory_girl, da própria empresa que criou o Shoulda. É ótimo, sugiro o uso.

Simulei alguns cenários e acredito que é mais provável que eu encontre um erro no comportamento dessa forma, pois fui obrigado a formular um exemplo. Quem é acostumado a unit/test geralmente olha essa situação como um pouco de overkill: o que faria em uma linha, demorou bem mais tendo que pensar nos exemplos e na construção do teste em si.

Mas, o foco de BDD é CLAREZA nos testes e não DRY. Nem sempre um teste deve ser DRY.

É claro que é perfeitamente possível fazer isso com Shoulda e outras libs. A questão é: macros como should_have_named_scope induzem a esquecer o comportamento em benefício da simplicidade e rapidez em escrever o teste.

After all, it’s a matter of taste..

Escolher entre Shoulda e RSpec é uma questão de gosto, como eu falei no começo. Ou você gosta de focar seus testes no comportamento de um objeto, ou você prefere utilizar asserções do test/unit.

Para finalizar, volto a dizer que estamos falando aqui de BDD e TDD, e o objetivo aqui não é comparar frameworks nem gerar flames. “Shouldeiros”, não me crucifiquem por favor
E opiniões são bem vindas sobre isso tudo.

Obrigado!

Para os residentes da região metropolitana de Porto Alegre – RS, estão abertas vagas para a Formação Desenvolvedor Web com Ruby on Rails, a ser realizada no Instituto de Informática Unisinos.

Mais detalhes da formação.

A carga horária é de 80 horas, dividia em 3 módulos. A estrutura está adequada tanto para profissionais que já programam em outras linguagens como iniciantes. Na página acima têm todos os detalhes

Este cenário surgiu da necessidade de sincronizar o desenvolvimento de mais pessoas num projeto Rails (usando GIT), no que diz respeito a vendor branches externos (plugins). Quando se usa SVN, instalar plugins no Rails com ./script/plugin install -x parece uma maravilha até o momento que você começa a alterar seus plugins.. Quando faz isso, não pode comitá-los, e fica no impasse sobre o que fazer. Nem preciso comentar o quão estranho seria mandar patchs para equipe…

As premissas, antes de tudo, eram:

1. Não usar SVN.
2. Flexibilidade para SVN e GIT como repositórios remotos.
3. Possibilidade de trabalhar em ambiente multiusuário, ou seja, vários desenvolvedores.

Deixe-me explicar a primeira premissa: Usar Subversion implicaria em merges a cada atualização dos plugins. Independente da solução que fosse usada para o merge de um plugin (piston, svnmerge, svn_load_dirs), o Subversion não trabalha bem com arquivos removidos/renomeados/movidos. Seja qual for a estratégia, o fato de fazer merge em repositórios diferentes no Subversion é um “tiro no escuro”: você nunca sabe está realmente idêntico ao repositório que você sincronizou, principalmente quando há mudanças drásticas neles (arquivos removidos/renomeados/movidos), e vai deixando seu rastro de desorganização com o tempo. No site do Piston eles também comentam sobre isso.

continue reading »

Uma dica rápida para fazer o deploy usando remote_cache e mongrel_cluster. Antes da dica, uma introdução nos temas abordados:

Capistrano é uma ferramenta que, a grosso modo, permite realizar tarefas remotas de todos os tipos. Uma das aplicações comuns é no processo de deployment do Rails que é, de longe, facilitado pelo Capistrano

mongrel_cluster é, em suma, um Gem que agrupa um cluster de servidores de aplicação Mongrel, simplificando a tarefa de gerenciá-los.

Remote cache é uma estratégia de deployment do Capistrano que executa uma tarefa interessante: ela faz um clone do repositório GIT (ou um checkout, se for Subversion) e atualiza a aplicação apenas com um rsync, ou seja, copia apenas os arquivos modificados para a release atual.

continue reading »

É com muita satistafação que anuncio a nova formação “Desenvolvedor Web com Ruby on Rails”, a ser realizada aos sábados no Instituto de Informática – UNISINOS em São Leopoldo, Rio Grande do Sul (região metropolitana de Porto Alegre).

Como o nome sugere, é uma formação bastante abrangente que envolve não apenas o desenvolvimento de aplicações com Ruby on Rails, mas também módulos de HTML/Webstandards e SQL, provendo uma base necessária para construir aplicações web completas.

A carga horária em Ruby e Rails é forte. Serão 60 horas no total (20-Ruby, 40-Rails) onde propõe-se uma formação consistente em tópicos não só básicos, mas também deployment, RESTful, etc, assim como o desenvolvimento de uma aplicação com contexto real e útil.

Cabe um comentário pessoal aqui: Estou bastante satisfeito em pensar que esta é mais uma iniciativa visando a divulgação do Ruby on Rails no Brasil. Espero contribuir ampliando a rede de desenvolvedores e boas aplicações saindo do Brasil. Ah, e nos veremos também no FISL, nos stand do Rails Brasil!

INFORMAÇÕES E INSCRIÇÕES:

Telefone e fax: (51) 3328-2221
Proposta on-line: http://www.ccti.unisinos.br/ccti_interna.php?corpo=faleconosco

DETALHES DA FORMAÇÃO:

Objetivo:
Capacitar os profissionais a desenvolver aplicações Web utilizando os recursos do framework Rails e da linguagem Ruby, seguindo os princípios e práticas que norteiam o modelo de desenvolvimento ágil.

Público-Alvo:
Desenvolvedores PHP, Java, .NET e/ou outras linguagens; Programadores com pouca ou bastante experiência.

Pré-requisitos:
Conhecimentos em ambiente Windows ou Linux; Noções básicas de programação; Desejável conhecimento em Orientação a Objetos.

Realização da formação: De 29/03 à 05/07
Local: Câmpus Unisinos – São Leopoldo
Horário > Sábado 08:30 até 12:30 e das 13:30 até 16:00

CONTEÚDO PROGRAMÁTICO:

HTML e WebStandards – 20 horas -> apresenta a linguagem HTML e os últimos padrões de desenvolvimento de páginas para Web, incluindo os Web Standards, a linguagem XHTML, e o desenvolvimento de páginas utilizando CSS e Tableless Design.
Realização: 29/03/2008 – 12/04/2008 – São Leopoldo

Linguagem SQL Padrão ANSI – 20 horas
Realização: 19/04/2008 – 03/05/2008 – São Leopoldo

Introdução à linguagem Ruby – 20 horas -> Compreender a linguagem Ruby e a aplicabilidade de suas principais funcionalidades para otimizar a construção de algorítimos.
Realização: 10/05/2008 – 24/05/2008 – São Leopoldo

Ruby on Rails prático – 40 horas -> Capacitar o aluno a desenvolver aplicações web com o framework Rails utilizando seus principais recursos, melhores práticas e técnicas de desenvolvimento, voltadas a projetos e cenários reais.
Realização: 31/05/2008 – 05/07/2008 – São Leopoldo

Divulgando aqui o mini-curso de Introdução ao Ruby on Rails que ocorrerá no 19/10 na Semana Acadêmica da Informática Unisinos (Uniinfo 2007)

19/10 – 13h às 16h
Minicurso: Introdução ao Ruby on Rails
Ministrante: Jony dos Santos Kostetzer
Local: Sala 6L 118
Objetivo: Conhecer alguns conceitos, recursos e práticas no desenvolvimento de aplicações em ambiente web utilizando a linguagem Ruby e o framework Rails.
Conteúdo: Introdução à linguagem Ruby; Instalaçao em amb. Windows e Linux; IRB; Modelo MVC; Introdução ao Rails; Primeiros passos; Relacionamentos; Ajax; IDEs; Atualidade e futuro do RoR.

Quem é estudante da Unisinos ou reside na região e gostaria de conhecer um pouco a linguagem Ruby e o framewok Rails, fica o meu convite

Importante:

• É necessário fazer a inscrição no evento através do site
• É solicitado aos inscritos que informem ao coordenador do evento (pelo e-mail cazella@unisinos.br) se desejarem realizar o minicurso: NOME COMPLETO, E-MAIL e NOME DO MINICURSO (Introdução ao Ruby on Rails). Este controle torna-se necessário devido ao número de vagas disponíveis ser limitado para minicursos.

Conto com a presença de vocês!

UPDATE: Muito obrigado pela presença de todos! Foi um ótimo encontro

Aqui estão os slides conforme prometido: Introdução ao Ruby on Rails

Até a próxima!