Uma grande característica do cucumber é que você pode criar seus testes na sua lingua nativa, facilitando ainda mais o processo e a integração com o cliente.
Recentemente o cucumber mudou a forma de se rodar as features em outra lingua, então vim aqui postar como ficou na nova versão (a partir da versão 0.5.0).
Primeiramente, para listar os idiomas que o cucumber suporta, basta digitar o comando:
Para nosso exemplo, vamos configurar ele em português.
O cucumber trabalha com um arquivo chamado web_steps.rb (que antes se chamava webrat steps) que trás os steps mais utilizados já configurados. Você pode traduzir esse arquivo do modo que preferir para o português, ou utilizar a versão já traduzida pelo pessoal do cucumber, gerando-o com o comando que configura o cucumber no Rails dessa forma:
Com isso você terá um arquivo chamado features/step_definitions/web_steps_pt-BR.rb
Antes para executar as features em português você tinha que passar a linguagem para o cucumber através do parâmetro -language. Hoje esse parâmetro não existe mais, e para configurar sua feature em português basta adicionar a seguinte linha no começo do arquivo:
A partir daí você já pode criar suas features em português, um exemplo:
Para listar as palavras chaves do cucumber em português você pode digitar:
Bom, espero ter ajudado.
Até o próximo post!
sexta-feira, 29 de janeiro de 2010
sábado, 23 de janeiro de 2010
Counter cache, Ruby on Rails
Um recurso interessante do Rails para otimização de desempenho é o counter_cache.
Por exemplo, na página inicial de uma aplicação que estou trabalhando nós exibimos uma lista de eventos, e cada um desses eventos tem um ou mais orçamentos (Event has_many :budgets).
Nós temos que exibir numa coluna a quantidade de orçamentos existentes desses eventos. Para isso uma solução seria fazer um SELECT COUNT para cada evento (listamos 30 eventos por página, então seriam 30 consultas) ou poderíamos fazer um SQL mais elaborado no começo para consultar já com os counters, o que poderia sair um pouco do padrão ou até complicar um pouco o código.
Para solucionar meu problema eu acionei a opção de counter_cache no relacionamento belongs_to da minha classe Budget:
Sendo assim, o Active Record entende que existe um campo chamado budgets_count na tabela events, que ele atualiza toda vez que eu adiciono ou removo um orçamento de um evento.
Na hora de listar os eventos na página inicial, ao invés de fazer um SELECT para cada um dos eventos, eu vou direto nesse contador gerado pelo Active Record.
O desempenho fica muito melhor porque eu visualizo muito mais a página inicial do que cadastro orçamentos, então vale mais a pena deixar o Rails atualizar esse número na hora do cadastro, do que fazer essa conta toda vez que eu exibo. Além disso, para o Rails atualizar esse contador não demanda muito processamento, uma vez que ele não calcula efetivamente quantos itens tem toda hora que eu salvo, e sim incrementa ou decrementa o contador a partir do número atual.
Como fazer
Vou explicar passo a passo como configurar. Vamos criar um exemplo aonde eu tenho a classe Album e a classe Picture. E um album tem muitas pictures.
Primeiramente, vamos configurar nossa classe Picture para dizer que o relacionamento belongs_to dela em relação a Album deve ter counter_cache.
O model de Picture ficaria assim:
E o model Album:
Quando colocamos a opção counter_cache como true, o Active Record entende que na tabela albums existirá uma coluna com o nome pictures_count (nome da tabela + '_count'). Se você quiser utilizar um campo com um nome diferente, basta informar no lugar do true, exemplo: :counter_cache => 'my_custom_counter'
Agora temos de criar o campo na tabela albums. Vamos fazer uma migração para adicionar esse campo (caso o modelo já exista):
Com o comando acima a migração será gerada quase pronta, você só precisará adicionar :default => 0 no campo pictures_count, deve ficar assim:
Agora vamos testar para ver se funciona. Segue abaixo alguns comandos que executei no terminal para criar um álbum com duas fotografias:
Agora vamos analisar o SQL gerado para esses comandos:
Ele consultou o banco para buscar as colunas de Album e Picture, depois fez os INSERTS e UPDATES para atualizar os contadores. Mas no final, quando solicitei solicitei a quantidade de fotografias do último álbum, ele apenas buscou o álbum mas não precisou fazer um SELECT COUNT para saber quantas tinhas, ele utilizou o cache.
Se o cache não existisse, você veria também o SQL abaixo:
Pode parecer pouco, mas numa página que é muito requisitada, e que exibe muitos registros, pode fazer diferença. Principalmente em épocas de servidor congestionado.
Existem algumas outras formas interessantes de cache que o Rails oferece, como o cache de página, de action, de fragmento, de SQL, entre outros.
Você pode ler a respeito deles em:
http://guides.rubyonrails.org/caching_with_rails.html
Talvez mais pra frente eu fale de outros caches aqui no Blog.
Bom, é isso pessoal, espero ter ajudado. Qualquer dúvida ou opiniões podem postar comentários ou entrar em contato comigo através de e-mail, twitter, gtalk, etc.
Abraços e até o próximo post.
Por exemplo, na página inicial de uma aplicação que estou trabalhando nós exibimos uma lista de eventos, e cada um desses eventos tem um ou mais orçamentos (Event has_many :budgets).
Nós temos que exibir numa coluna a quantidade de orçamentos existentes desses eventos. Para isso uma solução seria fazer um SELECT COUNT para cada evento (listamos 30 eventos por página, então seriam 30 consultas) ou poderíamos fazer um SQL mais elaborado no começo para consultar já com os counters, o que poderia sair um pouco do padrão ou até complicar um pouco o código.
Para solucionar meu problema eu acionei a opção de counter_cache no relacionamento belongs_to da minha classe Budget:
Sendo assim, o Active Record entende que existe um campo chamado budgets_count na tabela events, que ele atualiza toda vez que eu adiciono ou removo um orçamento de um evento.
Na hora de listar os eventos na página inicial, ao invés de fazer um SELECT para cada um dos eventos, eu vou direto nesse contador gerado pelo Active Record.
O desempenho fica muito melhor porque eu visualizo muito mais a página inicial do que cadastro orçamentos, então vale mais a pena deixar o Rails atualizar esse número na hora do cadastro, do que fazer essa conta toda vez que eu exibo. Além disso, para o Rails atualizar esse contador não demanda muito processamento, uma vez que ele não calcula efetivamente quantos itens tem toda hora que eu salvo, e sim incrementa ou decrementa o contador a partir do número atual.
Como fazer
Vou explicar passo a passo como configurar. Vamos criar um exemplo aonde eu tenho a classe Album e a classe Picture. E um album tem muitas pictures.
Primeiramente, vamos configurar nossa classe Picture para dizer que o relacionamento belongs_to dela em relação a Album deve ter counter_cache.
O model de Picture ficaria assim:
E o model Album:
Quando colocamos a opção counter_cache como true, o Active Record entende que na tabela albums existirá uma coluna com o nome pictures_count (nome da tabela + '_count'). Se você quiser utilizar um campo com um nome diferente, basta informar no lugar do true, exemplo: :counter_cache => 'my_custom_counter'
Agora temos de criar o campo na tabela albums. Vamos fazer uma migração para adicionar esse campo (caso o modelo já exista):
Com o comando acima a migração será gerada quase pronta, você só precisará adicionar :default => 0 no campo pictures_count, deve ficar assim:
Agora vamos testar para ver se funciona. Segue abaixo alguns comandos que executei no terminal para criar um álbum com duas fotografias:
Agora vamos analisar o SQL gerado para esses comandos:
Ele consultou o banco para buscar as colunas de Album e Picture, depois fez os INSERTS e UPDATES para atualizar os contadores. Mas no final, quando solicitei solicitei a quantidade de fotografias do último álbum, ele apenas buscou o álbum mas não precisou fazer um SELECT COUNT para saber quantas tinhas, ele utilizou o cache.
Se o cache não existisse, você veria também o SQL abaixo:
Pode parecer pouco, mas numa página que é muito requisitada, e que exibe muitos registros, pode fazer diferença. Principalmente em épocas de servidor congestionado.
Existem algumas outras formas interessantes de cache que o Rails oferece, como o cache de página, de action, de fragmento, de SQL, entre outros.
Você pode ler a respeito deles em:
http://guides.rubyonrails.org/caching_with_rails.html
Talvez mais pra frente eu fale de outros caches aqui no Blog.
Bom, é isso pessoal, espero ter ajudado. Qualquer dúvida ou opiniões podem postar comentários ou entrar em contato comigo através de e-mail, twitter, gtalk, etc.
Abraços e até o próximo post.
Assinar:
Postagens (Atom)