Desenvolvimento Ágil - Blog da Improve It: Tag rails

Como Testar parte 2 - Mocks

Marcos Tapajós — Sun, 16 Nov 2008 18:22:13 -0200

Tem gente "chutando" Demeter.

Minha idéia era escrever um post dessa série por semana, mas infelizmente uma tendinite tem me atacado e está meio complicado ficar escrevendo muito. Por isso mesmo esse segundo artigo será bem compacto. Todos os códigos citados nesse post fazem parte de um projeto How Test que está disponível em: http://github.com/tapajos/how-test

Nesse post a minha idéia é mostrar de forma bem simples como funciona um mock object no Rspec e no Test::Unit(usando o mocha).

Para exemplificar eu vou fazer uma crítica a uma construção que eu tenho visto muito em diversos projetos e que viola a Lei de Demeter(Principle of Least Knowledge). Ou como dizia, o meu amigo, Bernardo, "Tem gente chutando Demeter!".

Vamos a um exemplo dessa violação:

Supondo que você tenha um modelo Account que se relaciona ao modelo User.

class Account < ActiveRecord::Base
  belongs_to :user
end

Freqüentemente eu vejo construções do tipo:

@account.user.name
@account.user.mail
@account.user.rg.number
@account.user.rg.state
@account.user.rg.city

O grande problema é que nesse tipo de construção você está "conhecendo" coisas demais e certamente vai pagar por isso num futuro breve, quando você precisar fazer um refactoring e tiver que mudar em vários lugares. Imagina se o User deixa de ter um "name" e passa a ter um "full_name".

Para resolver esse tipo de problema basta você concentrar esse "conhecimento" no seu modelo Account da seguinte forma:

class Account < ActiveRecord::Base
  belongs_to :user
  def user_name
    user.name
  end
end

OBS: Vou me concentrar apenas no problema com o nome e não vou me preocupar em validar se o relacionamento foi estabelecido.

Bem, finalizada a crítica a uma falha de design OO vamos ao objetivo desse post, mostrar como *EU* testaria esse problema.

Como eu falei no post anterior, não gosto muito de usar fixtures para testes unitários e por isso mesmo vou apelar aos mock objects. Se você não está muito familiarizado com mocks sugiro que pare por aqui e leia um pouco mais sobre isso. Uma referência rápida pode ser o wikipedia mas realmente sugiro que vá mais adiante.

Testando usando RSpec(usando o framework de mock padrão):

before(:each) do
  @account = Account.new    
  @user_mock = mock_model(User)
  @account.stub!(:user).and_return(@user_mock)
end

describe ".user_name" do

  it "should delegate to user.name" do
    @user_mock.should_receive(:name).and_return("Tapajós")
    @account.user_name.should == "Tapajós"
  end

end

Testando usando Test::Unit com mocha:

setup :create_model

def test_user_name
  @user_mock.expects(:name).returns("Tapajós")
  assert_equal "Tapajós", @account.user_name
end

private

  def create_model
    @account = Account.new
    @user_mock = mock("User")
    @account.stubs(:user).returns(@user_mock)
  end

Explicando...

Em ambos os casos eu preciso que a minha account simule o relacionamento com User e para isso eu vou retornar um mock object. Isso é feito pelas linhas:

RSpec:

@account.stub!(:user).and_return(@user_mock)

Test::Unit:

@account.stubs(:user).returns(@user_mock)

Após o setup ou o before, temos um modelo @account onde o @account.user retorna um mock.

Feito isso eu preciso configurar o meu mock, isto é, informar que ele receberá uma mensagem name (chamada do método .name) e essa retornará o meu nome(sim, sou egocêntrico). Isso é feito pelos métodos "should_receive" e "expects" conforme as linhas abaixo:

RSpec:

@user_mock.should_receive(:name).and_return("Tapajós")

Test::Unit:

@user_mock.expects(:name).returns("Tapajós")

Depois que nossos mocks foram devidamente configurados podemos, finalmente, fazer nossa verificação do retorno, isto é, simplesmente chamar nossos métodos conferir o retorno. Pronto teste feito com sucesso, sem precisar recorrer a banco de dados nem configurar fixtures.

Nesse momento deve ter surgido uma dúvida: "Porque uma hora você usa stub! e outra um should_receive?"

A resposta é bem simples, o stub! não faz um verify no final enquanto a outra chamada sim. Na pratica isso significa:

Stub! ou stubs

Quando eu uso stub!(ou um Stubs) eu estou configurando o meu modelo account para responder pelo método user retornando o @mock_user porém não me interessa quebrar esse teste caso você não chame esse método.

Should_receive ou expects

Quando eu uso should_receive(ou um expects) eu estou configurando o meu mock user para responder pelo método name porém caso esse método não seja chamado eu devo quebrar meu teste, pois isso seria um comportamento indesejável.

Porque usar mocks?

Ao contrário do que muita gente pensa o uso de mocks não é um bicho de 7 cabeças, é bem simples. Na verdade testar é algo simples, desde que você tenha domínio do ferramental e os mocks são realmente úteis em diversos casos.

Imagina que o seu sistema precise fazer consultas a uma api publica do Yahoo e para isso você tenha criado uma classe de consultas. Você não vai querer(nem o Yahoo vai gostar) ir lá no servidor toda vez que você rodar os seus testes. Isso tornaria os seus testes lentos e impossível roda-los offline. Nesse caso você resolve seu problema "mockando" essa classe.

Como Testar parte 1 - Models

Marcos Tapajós — Sun, 26 Oct 2008 02:51:35 -0200

Quando comecei a estudar Extreme Programming descobri que não é possível fazer nenhum software de qualidade sem uma excelente base de testes. Desde então tenho me dedicado muito ao estudo das mais diversas ferramentas e técnicas para elaborar bons de testes.

O assunto testes é bastante polêmico e não pretendo (nesse post) tentar convencer ninguém da importância deles. Se você não faz testes e/ou discorda de qualquer uma das minhas afirmações deixo algumas perguntas para você refletir.

1 - Quantos bugs fixes você fez esse ano?

2 - Quantos tickets abertos existem no seu bug tracker?

3 - Quantas vezes você fez um deploy de uma nova versão em uma sexta feira de tarde e saiu mais cedo do trabalho?

4 - Quantas vezes você "virou a noite" esse ano?

Acabei me tornando um evangelizador de testes porém nunca fiz nada muito prático para passar o conhecimento que eu adquiri para a comunidade. Só que agora vou me redimir dessa falha iniciando uma série de posts onde vou expor um problema e como EU testaria usando Test::Unit e Rspec. Não vou falar de Shoulda pois não gosto dele. :-)

A idéia de escrever essa série de posts sobre testes surgiu logo após a gravação do terceiro episódio do RailsBox e gostaria de agradecer ao Ozeias e ao Davis Cabral por terem me motivado.

"Back to the cold cow..."

O ActiveRecord simplifica muito nossos modelos porém tenho observado que em vários projetos os desenvolvedores deixam de testar corretamente os seus modelos usando a alegação que não vão testar alguma coisa que o Rails já testou. Esse é um argumento valido em alguns casos pois você está apenas delegando responsabilidades mas você sempre deve testar se a responsabilidade foi realmente delegada.

Um exemplo clássico são as validações. Teoricamente você não precisaria testar como elas são implementadas mas deve testar se elas realmente existem pois se alguém remove-las seus testes vão continuar passando mas sua aplicação estará quebrada e/ou permitindo inconsistências de banco de dados.

Nesse post vou mostrar como testar alguns comportamento do ActiveRecord usando como base o modelo User. Todos os códigos citados nesse post fazem parte de um projeto How Test que está disponível em: http://github.com/tapajos/how-test

class User < ActiveRecord::Base
  validates_presence_of :name
  validates_format_of :mail, 
                      :with => /([-.\w^@]+@(?:[-\w]+.)+[A-Za-z]{2,4})+/i,
                      :on => :create,
                      :allow_nil => true
  has_many :accounts
  named_scope :actives, :conditions => ["active = ?", true]
end

Uma boa estratégia para orientar o desenvolvimento dos teste é elaborar algumas perguntas que darão origem aos seus cenários de testes.

Validação do nome

Posso cadastrar um usuário sem nome? Não

Testando usando Test:Unit:

def test_if_check_presence_of_name
  assert !@user.valid?, "Should be invalid"
  assert_equal "can't be blank", @user.errors[:name]
end

Na primeira linha desse teste o assert recebe um segundo parâmetro que por ser opcional não é muito comentado mas merece uma atenção especial. Esse argumento nada mais é do que a mensagem que será exibida quando o teste quebrar. Quando você omite esse parâmetro o teste quebra exibindo a mensagem 'false is not true' que não ajuda muito a entender o que está acontecendo.

Testando usando RSpec:

it "should reject if name is not given" do
  @user.should have(1).error_on(:name)
  @user.errors[:name].should == "can't be blank"
end

Validação do e-mail.

Posso criar um registro com um e-mail inválido? Não
Posso atualizar um regitro com um e-mail inválido? Sim
Posso criar um registro com um e-mail em branco? Sim

Testando usando Test:Unit:

VALIDS_MAIL = %w(foo@bar.com foo@bar.com.br foo@globo.com foo@i_hate_the_microsoft.com foo@i_love_my_mac.com)
INVALIDS_MAIL = %w(foobar.com foo@bar i_hate_the_microsoft.com i_love_my_mac.com)

def test_if_reject_invalid_format_os_mail_on_create
  INVALIDS_MAIL.each do |mail|
    @user.mail = mail
    assert !@user.valid?, "Should be invalid when mail is #{mail}"
    assert_equal "is invalid", @user.errors[:mail]
  end
end

def test_if_not_reject_when_mail_is_nil
  @user.name = "Tapajós"
  assert @user.valid?, "Should be valid"
end

def test_if_not_check_format_of_mail_on_update
  @user.name = "Tapajós"
  assert @user.save, "Should save"
  @user.mail = "an invalid mail"
  assert @user.valid?, "Should be valid"
end

def test_if_accept_a_valid_mail
  VALIDS_MAIL.each do |mail|
    @user.name = "Tapajós"
    @user.mail = mail
    assert @user.valid?, "Should be valid when mail is #{mail}"
  end
end

Testando usando RSpec:

INVALIDS_MAIL.each do |mail|
  it "should reject because #{mail} is an invalid mail" do
    @user.mail = mail
    @user.should have(1).error_on(:mail)
    @user.errors[:mail].should == "is invalid"
  end
end

VALIDS_MAIL.each do |mail|
  it "should be valid when mail is #{mail}" do
    @user.mail = mail
    @user.should_not have(1).error_on(:mail)
  end
end

it "should not reject if mail is not given" do
  @user.name = "Tapajós"
  @user.should be_valid
end

it "should not check mail format on update" do
    @user.name = "Tapajós"
    @user.save.should be_true
    @user.mail = "an invalid mail"
    @user.should be_valid
end

Testando o relacionamento com Account.

Um usuário pode ter mais de uma conta? Sim

Testando usando Test::Unit:

def test_has_many_accounts
  association = User.reflect_on_association(:accounts)
  assert association, "Association with account is not found"
  assert_equal :has_many, association.macro
end

Testando usando RSpec:

it "should has many accounts" do
  association = User.reflect_on_association(:accounts)
  association.should_not be_nil
  association.macro.should == :has_many
end

Testando o User.actives

Posso listar usuários inativos? Não

Testando usando Test::Unit:

def test_if_actives_use_the_correct_conditions
  assert_equal({:conditions=>["active = ?", true]}, User.actives.proxy_options)
end

Testando usando RSpec:

it "should find for all users that status of active is true" do
  User.actives.proxy_options.should == {:conditions=>["active = ?", true]}
end

Para esse post ficar mais simples e curto não me preocupei em validar se o tamanho máximo dos campos está coerente com o tamanho máximo permitido pelo tipo no banco de dados. Essa é uma validação EXTREMAMENTE importante que não deve ser esquecida!

No próximo post dessa série falarei um pouco sobre a Lei de Demeter, como respeita-la e testar alguns métodos usando Mock Objects.

O que você achou desse artigo? O que você gostaria de saber sobre testes de ActiveRecord que eu não falei aqui?

Aguardo o feedback de vocês.

Mais uma gem no Brazilian Rails

Marcos Tapajós — Tue, 23 Sep 2008 23:20:36 -0300

O Brazilian Rails acabou de ganhar uma gem para lidar com CPF e CNPJ desenvolvida pelo Cássio Marques. Ele fez um post no seu blog explicando como utilizar.

http://tinyurl.com/cpfcnpj

Além dessa nova gem a versão 2.0.8 do Brazilian Rails recebeu algumas pequenas correções feitas pelo Akita e pelo Sergio Brant.

Gostaria de agradecer aos três pelas colaborações.

Integration Plugin no Github

Marcos Tapajós — Fri, 05 Sep 2008 14:49:52 -0300

Acabamos de migrar o Integration plugin para o Github. As instruções de instalação podem ser conferidas na página do projeto em:

http://integration.rubyforge.org/

A página do projeto no Github é:

http://github.com/tapajos/integration

Saiu o Brazilian Rails 2.0

Marcos Tapajós — Sun, 31 Aug 2008 23:57:34 -0300

Finalmente terminamos a migração do plugin Brazilian Rails para ser um conjunto de gems! Agora vamos começar duas novas empreitadas:

Migrar as gems que são específicas para o Rails para usarem o i18n.
Conversar com todos os desenvolvedores que possuem plugins específicos para brasileiros para transformar em gems e adicionar ao Brazilian Rails.

Vocês podem ver mais detalhes em:

http://www.improveit.com.br/software_livre/brazilian_rails

Entrevista com Marcelo Alvim, do Projeto Lucidus

Vinicius Manhães Teles — Tue, 19 Aug 2008 15:16:00 -0300

Há algumas semanas eu entrevistei os desenvolvedores do Projeto Lucidus. Abaixo a entrevista com o Marcelo Alvim, que faz parte da equipe da Improve It no projeto:

Quem tiver iPhone pode ver a entrevista no YouTube.

Link direto para o vídeo.
Download .flv
Download .m4v

Hotel para a Rails Summit

Marcos Tapajós — Wed, 30 Jul 2008 04:45:54 -0300

No meu último post eu comentei sobre o hotel em que ficaremos hospedados para a Rails Summit Latin America 2008 e algumas pessoas comentaram que o hotel está lotado.

Eu liguei lá no hotel e descobri que existem quartos disponíveis mas que eles liberam apenas alguns pela central 0800 e o resto só ligando direto para o hotel. Ou seja, quem quiser reservar é bom ligar para: 11-4506-9500

Rails Summit Latin America 2008

Marcos Tapajós — Tue, 29 Jul 2008 19:31:13 -0300

Em outubro teremos a maior conferência de Rails no Brasil, a Rails Summit Latin America 2008 que está sendo organizada pelo nosso amigo Fábio Akita. Será uma conferência de alto nível, com os grandes nomes internacionais e nacionais.

Eu irei ao evento juntamente com parte da equipe da Improve It e da Surgeworks. Esse evento também será uma ótima oportunidade de cair na farra com alguns amigos que não vemos sempre. Para facilitar a organização da bagunça que iremos fazer resolvemos que seria legal informar a todos o hotel que nós ficaremos para atrair mais adeptos a nossa farra!

Eu não conheço o hotel e não sei dizer se ele é bom ou ruim, apenas fui na indicação de uns amigos lá de SP e eu não conto que são todos da Surgeworks nem que me cortem o pescoço. Mas nem estou me preocupando com isso, só quero o hotel para dormir mesmo! :-)

Bem, que Deus proteja o hotel!

Em Julho: Ultra Maratona How To! Com cursos de Rails e XP!

Sylvestre Mergulhão — Sun, 06 Jul 2008 16:44:00 -0300

Nos dias 19 e 20 de julho teremos no Rio de Janeiro a I Ultra Maratona How To de Software Livre! É um evento com 20 tutoriais práticos de 4 horas cada. Terão desde cursos de utilização de BrOffice e Inkscape, passando por segurança de servidores, hardening e desenvolvimento. Para ver a grade completa acesse. Os preços são bem convidativos.

Eu serei tutor de dois. O primeiro, com nome de "XP Game e o Jogo da comunicação", será em conjunto com o Tapajos e a galera do Lucidus. No segundo estarei sozinho e será uma "Introdução ao Ruby on Rails".

Acesse já e faça a sua inscrição, as vagas são limitadas.

Integration Plugin com GIT

Marcos Tapajós — Wed, 25 Jun 2008 20:31:35 -0300

Agora o Integration Plugin suporta GIT!

Desde o lançamento do Integration Plugin eu tinha a sensação que faltava o suporte ao GIT porém como o plugin foi extraído dos nossos códigos e não usávamos esse SCM ele foi lançado assim mesmo.

Logo depois o Eduardo Fiorezi me enviou um patch adicionando esse suporte e posteriormente o suporte ao git-svn só que eu não aceitei de imediato pois faltava documentar e eu estava completamente sem tempo para isso. Só que hoje recebi um patch do Sylvestre Mergulhão atualizando a documentação.

Obrigado aos dois!

Agora é a hora!

Marcos Tapajós — Mon, 23 Jun 2008 00:24:45 -0300

Como eu falei no meu outro post, nós estamos refatorando o Brazilian Rails e essa é a hora para quem quiser dar grandes sugestões e/ou colaborações. Quem quiser comentar algo ou faça agora ou cale-se para sempre! :-)

Tudo que estamos mexendo está em um branch chamado gems lá no Github. Para baixar o código basta seguir esses passos:

git clone git://github.com/tapajos/brazilian-rails.git
cd brazilian-rails
git checkout --track -b gems origin/gems

O futuro do Brazilian Rails

Marcos Tapajós — Sat, 21 Jun 2008 21:10:26 -0300

Já faz um bom tempo que o Tino conversou comigo sobre rescrever o Brazilian Rails só que nós fomos adiando e acabou não saindo nada. Freqüentemente nós recebemos várias sugestões e queria dizer que todas estão sendo analisadas e algumas já estão na nossa agenda(no meio digital dois corpos ocupam o mesmo espaço!).

Essa semana o Cássio e o Hallison deram a sugestão de modularizar o plugin para poder instalar apenas o que é realmente útil para um determinado projeto. Foi uma sugestão que não é inédita mas que eu juntei com uma outra que eu recebi faz um bom tempo que é transformar o plugin em uma gem para não precisar instalar em cada projeto.

A idéia é tornar um Brazilian Rails em um conjunto de gems de forma bem semelhante ao Rails mas que poderá ser usado como plugin da mesma forma como é usado hoje. Bem, esse é o futuro!

Pois bem, fiz um branch chamado gems lá no nosso repositório e já estou trabalhando na futura versão do Brazilian Rails. Se alguém quiser olhar e dar sugestões..

O primeiro livro sobre Rails 2.1 é brasileiro!

Marcos Tapajós — Fri, 06 Jun 2008 15:23:37 -0300

Eu e o Carlos Brando acabamos de liberar o primeiro livro sobre Rails 2.1.

Quem quiser ver mais detalhes é só olhar o post que o Carlos fez.

Bug no Selenium on Rails será corrigido!

Marcos Tapajós — Wed, 21 May 2008 00:00:10 -0300

Em janeiro desse ano eu publiquei um post relatando um bug no plugin Selenium on Rails e até hoje o ticket estava aberto. Durante esses 5 meses eu recebi vários e-mails de pessoas que chegaram ao meu post mas não entendiam o idioma e para todas elas eu respondia como corrigir e reclamava que o projeto parecia abandonado.

Recentemente eu entrei em contato com o Danilo Sato para ver se ele descobria, lá na ThoughtWorks, quem era o dono do projeto só que não tivemos muito sucesso. Eu estava quase pensando em fazer um fork mas hoje tive uma resposta do meu ticket e acredito que o projeto voltará a ser mantido. O Eric vai aplicar o patch que eu mandei e finalmente as pessoas vão poder usar o plugin com o Rails 2.0 sem ter que marretar o código.

Antes tarde do que nunca!

Brazilian Rails no github

Marcos Tapajós — Tue, 22 Apr 2008 15:33:13 -0300

Acabei de terminar a migração do plugin Brazilian Rails para o github. Achei que ia ser bem mais complicado do que foi ! :-)

Nós decidimos manter o SVN como um espelho (por um tempo) para facilitar a instalação nas versões anteriores a Rails Edge. Agora existem duas formas de instalação que estão detalhadas na página do plugin.

Para quem quiser acompanhar o projeto a url no github é:

http://github.com/tapajos/brazilian-rails

Novidades no Brazilian Rails

Marcos Tapajós — Thu, 17 Apr 2008 18:54:46 -0300

O Tino acabou de publicar no blog dele as últimas mudanças do Brazilian Rails.

Nova Página para o Brazilian Rails

Marcos Tapajós — Tue, 25 Mar 2008 19:47:57 -0300

Hoje o Brazilian Rails ganhou um site um pouco mais bonitinho com um design igual ao do nosso outro plugin.

Na verdade esse é um template, de autoria do Leandro, que será usado em todos os nossos plugins. Só não está mais bonito pois resolvi meter a mão e me antecipar ao Leandro.

Brazilian Rails: Patch aceito.

Marcos Tapajós — Tue, 25 Mar 2008 05:44:23 -0300

Como sempre estou atrasado e só hoje vi alguns patch no Brazilian Rails.

Patch #17896 - usar_como_dinheiro não funciona com audit.

O Sylvestre Mergulhão identificou uma incompatibilidade do plugin com o audit que não fazia log das colunas mapeadas com o usar_como_dinheiro. O patch que ele enviou já foi aceito.

Patch #18822 - Criação de metodos para que o select_estado funcione com o form_for.

Esse patch foi enviado pelo Rafael Cardoso e é bastante pertinente só que não foi aceito ainda pois o patch foi gerado de forma incorreta. Ele já fez contato comigo e vai enviar o patch correto em breve.

Queria agradecer aos dois pela colaboração constante. Já perdi a conta de quantas vezes aceitei código deles.

Brazilian Rails API

Marcos Tapajós — Wed, 19 Mar 2008 16:10:58 -0300

Agora a API do plugin Brazilian Rails está hospedada no RubyForge.org.

O endereço é: http://brazilian-rails.rubyforge.org/api.

Dentro de alguns dias teremos um site com uma documentação mais completa do plugin. Será uma página semelhante a do nosso outro plugin, o Integration.

Onde foram parar aqueles caras da Improve It?

Vinicius Manhães Teles — Thu, 13 Mar 2008 08:55:52 -0300

Há pouco mais de dois meses nós decidimos mudar de rumos e deixar os serviços de consultoria de lado. De lá para cá, estamos bem quietos. Afinal, o que anda acontecendo por aqui? Resumidamente, resolvemos começar nossa jornada resolvendo um problema bem concreto, para então começar a trabalhar no nosso primeiro produto.

Problema

A gente acha que bons produtos são extraídos de projetos reais, que resolvem o problema de alguém e podem ser re-estruturados para resolver o problema de muitos. Sendo assim, ainda em dezembro, na mesma época que anunciamos nossa saída do mercado de consultoria, começamos a trabalhar para um cliente. Trata-se de um negócio pequeno, porém extremamente bem sucedido, que atua em um ramo que movimenta uma boa grana. Ou seja, o negócio é pequeno, mas há dinheiro circulando o tempo todo. Por enquanto, não iremos revelar nem quem é o cliente e nem qual é a área de negócio, mas, para facilitar a história que vem a seguir, vou dar um nome fictício ao nosso cliente. Vamos supor que chama-se Júlia.

Júlia tinha um site. Não era dos melhores, mas era tolerável. Era parecido com muitos outros de pessoas que atuam no mesmo ramo. Este ramo é interessante porque a maioria dos sites é horrível e partem de uma premissa que, na nossa opinião, é profundamente equivocada. Nossa missão era dar um novo site à Júlia. Mas, não apenas isso. Este site teria que ter algumas funcionalidades que poderiam ajudá-la a acelerar seus processos. Ou seja, há um aspecto institucional, de apresentar o trabalho e outro funcional muito forte e, tipicamente, mal resolvido. Resolvemos tratar deste último de maneira inovadora, mas não foi só aí que decidimos inovar. Também queríamos quebrar a premissa fundamental que rege a maioria dos sites deste ramo.

Primeiro Ato

Dividimos o projeto em duas partes, que vou chamar de primeiro ato e segundo ato. O primeiro ato foi implementado em pouco mais de um mês e colocado no ar por volta do dia 10 de fevereiro de 2008. Na equipe, eu, o Tapajós e o Leandro trabalhando nisso em torno de trinta horas por semana.

Durante o desenvolvimento, estivemos próximos da Júlia o tempo todo. Conversamos muito sobre cada aspecto do sistema e fizemos inúmeros experimentos, sobretudo com a interface do usuário. Além disso, tentamos simplificar tudo que podíamos. A premissa era: preguiça é bom! Sim, quando se trata de desenvolvimento de software, há um certo tipo de "preguiça" que nos alerta quando estamos fazendo algo de forma excessivamente complicada. Foi esta preguiça que nos levou, por exemplo, a não usar banco de dados para praticamente nada. A única exceção é o armazenamento de sessões. Devido a algumas características do aplicativo, não dava para usar sessões baseadas em cookie.

É possível fazer um software significativo sem banco de dados? Ou melhor, dá para fazer sem persistência? Neste aplicativo, em particular, não dava para fazer sem persistência, mas dava para ficar sem banco de dados. Quer dizer que usamos algo tipo prevalência de objetos? Não exatamente. Há muita informação persistida, mas nós não tivemos que cuidar diretamente desta persistência e isso nos poupou muito trabalho. Os detalhes eu vou ficar devendo, lamentavelmente. Mas, posso dar uma idéia de números para vocês. Os dados persistidos podem levar o site a ter uma grande quantidade de páginas internas. Neste momento, o sitemap contém 15.133 páginas. Entretanto, este número é menor que o número real de páginas que ele possui. Como ficaria muito custoso gerar um sitemap completo, nós decidimos fazer um corte. Em todo caso, isso dá uma idéia da quantidade de dados que são persistidos e usados no site, porém, surpreendentemente, não há banco de dados envolvido! :-)

Há um detalhe interessante nesta questão. Se há tantos dados, como a Júlia faz para cadastrar estes dados e mantê-los? Boa pergunta. Não dá para explicar aqui como isso é feito, mas basta dizer que sim, há uma área administrativa, onde ela manipula todos os dados com uma interface bacana. Mas, a melhor parte da história é que nós não tivemos que fazer isso, o que, considerando a sofisticação da aplicação, explica como fizemos tudo em pouco mais de um mês.

Qualidade

Linhas de código não indicam quase nada isoladamente, mas, quando usadas em certas comparações, servem para dar uma idéia de características do projeto. Até o momento, temos 742 linhas de código na aplicação e 1934 linhas de specs. Isso significa que temos 2.6 linhas de spec para cada linha de código da aplicação. Aliás, não há uma única linha de código da aplicação que não receba a visita de pelo menos um spec. Ou seja, nossa cobertura de código pelos testes é de 100%, como em todos os nossos projetos. Além dos specs, temos inúmeros testes de aceitação no Selenium que totalizam 2136 checagens. Estes últimos testes consomem, em média, de 5 a 8 minutos para executar e são executados sempre que fazemos uma integração (com o plugin integration). Estes números mostram que temos uma preocupação significativa com a questão da qualidade.

Além dos testes automatizados, nós também realizamos testes manuais em cinco navegadores: IE6, IE7, Firefox, Opera e Safari. Estes testes têm o objetivo de inspecionar visualmente a parte do design, já que este é um terreno ainda complicado para os testes automatizados. Qualquer mudança no site leva, inevitavelmente, a testes manuais nestes navegadores, além dos automatizados. Em todo caso, há um tipo de checagem automatizada que podemos fazer para a parte do design. Trata-se das validações da W3C. O aplicativo passa nas validações da W3C. Desde o início do projeto o Leandro, sobretudo, tem demonstrado muita preocupação em assegurar que o aplicativo respeite todos os web standards.

Os números relacionados aos testes são elevados, mas, quando o assunto é gestão de bugs, os números já não são tão expressivos. Para começo de conversa, não temos nem mesmo um sistema de gestão de bugs. Pois é, que desorganizados nós somos, né? Nenhum sistema para gerenciar chamados e controlar os bugs. A sim, agora lembrei o porquê disso. Não tivemos nenhum relato de bug desde que o sistema foi ao ar! E não foi por falta de uso. Então, acho que dá para continuar sem gestão de bugs. Mas, garanto que seria impossível fazer isso sem a relação quase paranóica que nós temos com os testes.

Sendo bem honesto, a falta de relatos de bugs não significa que eles não existam. Significa apenas que não foram descobertos ainda. De fato, havia alguns que nós próprios conseguimos detectar depois de colocar o sistema no ar. Nenhum deles era grave e talvez ninguém nem tenha chegado a passar por eles. Mas, nós corrigimos assim que identificamos. Em todo caso, já faz vários dias que não conseguimos detectar nada novo e continuamos sem nenhum relato de bug, apesar de termos uma utilização crescente da aplicação.

Hospedagem e Deployment

Estamos usando o VPS de 512MB da SliceHost. Até o momento, o serviço deles tem sido perfeito. A máquina é muito rápida e estável. De fato, ela é superestimada para as necessidades desta aplicação. Mas, preferimos que seja assim. Nós fizemos inúmeros testes de desempenho com o Httperf antes de lançar o site e eles demonstraram que o site tem um tempo de resposta excepcional, mesmo quando a carga é muito elevada. Parte disso, naturalmente, tem a ver com o trabalho cuidadoso que fizemos na parte de caching.

Este aplicativo tem a propriedade de não ter modificações muito freqüentes, embora tenha uma grande quantidade de dados. Em torno de 90% do site pode se beneficiar do cache mais eficaz que temos no Rails, que é o cache de página. Sendo assim, estamos usando cache de página na maior parte do site e o resultado não poderia ser melhor. Os 10% restantes felizmente representam as funcionalidades menos usadas, embora tenham sido as mais trabalhosas para implementar.

Quanto ao application server, inicialmente pensamos em usar o nginx com o Mongrel. Mas, antes de tentar esta alternativa, lembrei da apresentação que considerei a mais interessante no Minas on Rails e no Rio on Rails. Foi a do Eduardo Rocha, do O Curioso. Uma das coisas que me chamou a atenção foi que ele disse que usava um tal de LiteSpeed e que recomendava. Até então, eu jamais tinha ouvido falar do LiteSpeed. Conversei com o Eduardo antes de colocar a aplicação no ar e ele reforçou a preferência pelo LiteSpeed e a recomendação. Resolvemos experimentar e não poderíamos estar mais felizes. O LiteSpeed cuida de tudo e é muito fácil de usar. Atua como WebServer, Application Server e ainda distribui a carga para várias instâncias do Rails. No nosso caso, está configurado para usar até dez instâncias simultaneamente.

O LiteSpeed é muito estável, leve e rápido. No lado web server, é mais rápido e mais leve que o Apache. A integração com o Rails, através do LSAPI gera um desempenho superior ao do Mongrel. A única coisa que ainda não entendi é por que tanta gente usa o Mongrel quando poderia usar o LiteSpeed que é melhor em todos os aspectos que vimos até o momento. A sim, ele não é open source, mas não é necessário pagar por nenhuma licença, a menos que o site tenha que responder a um número superior a 150 requisições por segundo, o que ainda não é o nosso caso.

Fizemos testes de desempenho com Httperf e conseguimos simular até 4000 requisições por segundo para páginas em cache. Infelizmente não sabemos o limite real que o servidor agüentaria porque acima deste valor, a máquina que simula os acessos passa a operar com 100% de consumo de CPU, devido à grande quantidade de threads que são criadas para o teste. Até 4000 requisições por segundo, o servidor não chegava a consumir sequer 50% da CPU.

Segundo ato

No momento, estamos trabalhando na segunda parte do projeto que deve ser colocada em produção na próxima semana. A partir daí, a Júlia segue seu caminho e nós seguimos o nosso. Passaremos a trabalhar para generalizar o aplicativo que fizemos para ela. O objetivo, naturalmente, será permitir que o outros pequenos negócios, no mesmo ramo, possam fazer uso do mesmo aplicativo.

Resultados

Assim que o novo site da Júlia foi ao ar, ela começou a receber inúmeros comentários de clientes e pessoas do mesmo ramo elogiando o trabalho. Houve pouquíssima crítica. As apostas que nós fizemos se revelaram certeiras. Agora, inúmeros colegas dela, da mesma área de negócio e correlatas, perguntam-lhe quem fez o site e querem ter um igual. Que legal! :-) É claro que nós queremos atender a todos eles, mas ainda não é o momento. Não queremos fazer um site para cada pessoa. Queremos que todos usem um produto bem definido, que seja fácil para eles usarem e, sobretudo, que nos permita incorporar novos clientes com rapidez e facilidade. Por conta disso, a Júlia tem um acordo de sigilo conosco que a impede de dizer quem fez. Como não queremos ninguém nos fazendo perguntas sobre o site dela antes da hora, nem ela conta quem fez, nem eu conto para vocês o que nós fizemos. E assim nós vamos ficar por mais alguns meses, beleza? :-)

Uma das coisas que nós mais gostamos de saber é que o novo site está rendendo bons frutos para a Júlia. Duas coisas nos chamaram a atenção em particular. A primeira é que ela relatou que o número de pedidos diários de orçamento para seus serviços cresceu mais de cinco vezes desde que o site foi colocado no ar. Ela agora gasta muito mais tempo respondendo emails, mas este não é um problema assim tão ruim, né? :-) A outra coisa legal é que ela disse que agora os clientes já chegam respeitando-a muito mais. Eles olham o site e concluem que estão lidando com uma profissional de altíssimo nível, o que é mais do que verdade.

Estamos animados e continuamos trabalhando bastante. Por isso que não tem dado tempo para escrever muito. Felizmente, ontem conseguimos publicar o plugin integration e tem um outro que está no forno. Espero que possamos lançar em breve. Tem muita coisa legal vindo por aí.