Cursos presenciais de Ruby on Rails
Aproveitando o imenso sucesso que está sendo o curso Imersão Sys Deploy em parceria com e-Genial resolvi pesquisar sobre o interesse das pessoas em relação a cursos presenciais.
Estou em negociação com um centro de treinamento aqui no Rio de Janeiro e é possivel que fechemos uma parceria para cursos presenciais ligados a Ruby on Rails.
Além do Rio de Janeiro também tenho interesse em atingir outros estados. Por isso elaborei um pequeno questionário que será útil para verificar a viabilidade dos cursos presenciais no Rio e em outras cidades do Brasil. Vocês me ajudam a divulgar? Muito obrigado.
Link direto: https://spreadsheets.google.com/viewform?formkey=dGtKY0hyMjhqUEgxNnpHempISzlsbEE6MQ
0 comentários : 29.04.2010 10:35 PM
Curso de administração Linux e deploy de Apps Rails
Hoje eu e o Carlos Eduardo da e-Genial fechamos os últimos detalhes de um novo curso: Imersão Sys Deploy! Os alunos vão aprender tudo sobre como configurar adequadamente um VPS para rodar aplicações Rails usando Apache com Passenger, Mysql e deploy com Capistrano.
E de quebra ainda vão ter capítulos específicos para tratar de serviço smtp com postfix, backup, monitoramento e segurança. É um curso completo sobre administração de servidores por um preço imperdível!
E ainda tem mais! Cada aluno do curso terá acesso a um VPS exclusivo onde ele executará as tarefas junto comigo. As aulas serão aos sábados pela manhã pelo TreinaTom.
Para saber mais detalhes acesse já o site do curso e faça a sua inscrição, as vagas são limitadíssimas.
1 comentário : 23.02.2010 10:34 PM
Empreender, essa é a hora! - Parte 1
Há pouco mais de um ano atrás eu fiz uma palestra no Encontro de TI sobre Empreendedorismo on Rails. A apresentação bombou, fez o maior sucesso, mas até hoje eu não tinha dado nenhum feedback sobre o que eu mesmo estava fazendo em relação ao que preguei na palestra. O fato é que 2009 foi um ano de muito trabalho, onde eu comecei a preparar os alicerces do que vou apresentar hoje. É sempre bom lembrar que tudo foi e continuará sendo feito durante os tempos vagos.
Em 2009 me juntei com mais 3 empreendedores para criar a idéia do nosso produto. Ele tem um nome: Clientella. Trata-se de um CRM para pequenas empresas e profissionais liberais. Alguns pensarão: “Ah fala sério, vocês vão copiar o Highrise da 37signals”. Bom a idéia não é essa. Para nós de TI que estamos adaptados aos sistemas web e com o idioma inglês é simples usar um sistema gringo. Com o Clientella estamos pensando nas empresas que tem especificidades brasileiras, que buscam um serviço nacional, com suporte na própria língua e não necessariamente entendem algo de web.
“Da onde saiu essa idéia maluca de fazer um CRM? Esse nome é batido pra caramba e existem diversos players no mercado!”, vocês pensariam. Bom, eu trabalhei customizando o SugarCRM - um bloated CRM opensource - para uma empresa há uns 3 anos atrás. O que eu aprendi lá é o quanto as empresas precisam de um CRM e o quanto as soluções existentes não resolvem os problemas. Lembrando que estamos falando de pequenas empresas, logo qualquer coisa como Oracle, SAP, SalesForce e Microsoft está fora de cogitação apenas pelo custo de aquisição das licenças ou de necessidade de infraestrutura própria. Daí pode-se ver a quanto tempo estou maturando essa idéia de um CRM na cabeça ;-)
E o que você pode fazer para ajudar? Se você tem uma empresa ou é um profissional liberal e precisa de um CRM, acesse o nosso site, leia a carta convite e preencha o formulário. Assim você nos ajudará com o Clientella e ainda poderá se tornar parte do programa de beta testers.
5 comentários : 04.02.2010 12:57 AM
Fazendo thumbnails de tamanho fixo com attachment_fu
O plugin attachment_fu é quase que o plugin padrão para tratar do upload de arquivos em aplicações Rails. Ele suporta também o resize de imagens mantendo as proporções, mas não suporta crop. Sempre precisamos criar avatar ou coisas semelhantes. E em geral o avatar tem um tamanho fixo, como 80x80. Para isso é necessário fazer o crop da imagem. Adicione o método resize_image, como abaixo, no seu modelo:
class Photo < ActiveRecord::Base
belongs_to :owner, :class_name => "Person"
has_attachment :content_type => :image,
:processor => :rmagick,
:storage => :file_system,
:resize_to => '600>',
:thumbnails => {
:album => 'crop: 150x150',
:icon => '72>' }
protected
def resize_image(img, size)
# resize_image take size in a number of formats, we just want
# Strings in the form of "crop: WxH"
reg = /^crop: (\d*)x(\d*)/i
if (size.is_a?(String) && size =~ reg) ||
(size.is_a?(Array) && size.first.is_a?(String) &&
size.first =~ reg)
img.crop_resized!($1.to_i, $2.to_i)
# We need to save the resized image in the same way the
# orignal does.
self.temp_path = write_to_temp_file(img.to_blob)
else
super # Otherwise let attachment_fu handle it
end
end
end
Assim você sobrescreve o método original do attachment_fu para suportar uma sintaxe especial. Então quando você quiser um thumbnail ou até mesmo a imagem principal cortada de um tamanho específico, basta usar a string ‘crop: WxH’. Bom lembrar que isso só irá funcionar com o Rmagick. Eu dei uma olhada sobre como fazer usando o image_science, mas era um pouco mais chato. É bom setar: :processor => :rmagick na definição do has_attachment.
Eu também fiz um teste para garantir que os meus thumbnails estão sendo gerados no tamanho correto:
describe "photo resize" do
it "should create thumbnails with correct size" do
photo = new_photo
photo.save!
full, album, icon = *Magick::ImageList.new(
photo.full_filename,
photo.full_filename('album'),
photo.full_filename('icon')
)
full.columns.should == 50
full.rows.should == 64
album.columns.should == 150
album.rows.should == 150
icon.columns.should == 50
icon.rows.should == 64
end
end
PS1: Sim, eu sou paranóico com testes e você também deveria ser!
PS2: Essa dica foi adaptada daqui.
3 comentários : 17.03.2009 07:04 PM
Lançamento da Revista TI Digital
Ontem na Livraria da Travessa, centro do Rio, foi o lançamento da Revista TI Digital de autoria da Arteccom. A mesma do Encontro de TI, do Encontro de Webdesign e da Revista Webdesign.
Grandes nomes da área de desenvolvimento nacional estão entre os colunistas, como Paulino Michelazzo e Guilherme Chapiewski. Eu tenho o honra de estar nesse time também! Vou escrever sempre sobre Ruby on Rails. Nesta primeira edição tivemos uma entrevista exclusiva com o David H. Hansson e comentários de nomes da nossa comunidade como Carlos Eduardo, Ronaldo Ferraz, Paulo Souza e Carlos Brando.
No primeiro artigo eu falei um pouco sobre REST e sobre como facilitar a sua vida usando o plugin resource_controller do James Golick. Então vamos em frente. Aceito sugestões para os próximos artigos!
Compre na banca mais próxima de você!
2 comentários : 06.03.2009 07:59 PM
mergulhaoinfo no imasters
Para quem acompanha meu blog agora uma ótima notícia! Está com algumas semanas de atraso, mas antes tarde do que nunca… o tempo está escasso. A partir de agora alguns dos meus posts, principalmente os técnicos, também serão publicados dentro do iMasters! O primeiro post já foi publicado, é a série de três vídeos da palestra no Encontro de TI. Acesse o post no iMasters.
1 comentário : 06.03.2009 07:20 PM
E mais um podcast gravado!
Saiu no guanabara.info o episódio no. 53 do GuanaCast e eu fui o entrevistado da semana! Além do Gustavo Guanabara também participaram do podcast o Kauê Linden e o Sharuto da Hostnet. Foi um bate papo bem descontraído e divertido, explicando o básico do Ruby e do Rails, da onde a coisa apareceu, por que está fazendo tanto sucesso, etc. Não deixem de conferir!
Para ouvir, visite a página do podcast.
5 comentários : 01.02.2009 11:25 PM
Problema ao usar resources com palavras sem plural
No V2V nós criamos um resource que é utilizado para o formulário de contato (formmail) do site. O nome do resource é contact_us. O nosso routes.rb ficava assim:
map.resources :contact_us
E temos uma configuração de inflector para informar ao Rails que essa é uma expressão incontável:
ActiveSupport::Inflector.inflections do |inflect|
inflect.uncountable %w(contact_us)
end
O problema é que ao tentar gerar a url com o método contact_us_url para o formulário acontece o seguinte erro:
contact_us_url failed to generate from {:controller=>"contact_us", :action=>"show"} - you may have ambiguous routes, or you may need to supply additional parameters for this route. content_url has the following required parameters: ["contact_us", :id] - are they all satisfied?
Isso acontece pois o Rails sobrescreve o método que gera a url da coleção com o método que gera a url de instância dos objetos. Para resolver isso temos que informar no arquivo de rotas o nome que será utilizado nos métodos no caso de ser uma instância e não uma coleção:
map.resources :contact_us, :singular => :contact_us_item
Isso fará os métodos ficarem assim:
contact_us_path() => /contact_us
new_contact_us_item_path() => /contact_us/new
contact_us_item_path(1) => /contact_us/1
edit_contact_us_item_path(1) => /contact_us/1
Reparem que no caso de não ser usada a opção :singular o método de acesso a coleção e da instância ficam com nomes iguais:
contact_us_path() => /contact_us
contact_us_path(1) => /contact_us/1
Isso não acontece com expressões normais pois o Rails utiliza para a coleção a expressão com pluralize. Supondo que o nosso resource fosse de posts, os métodos seriam:
posts_path() => /posts
new_post_path() => /posts/new
post_path(1) => /posts/1
edit_post_path(1) => /posts/1
2 comentários : 22.01.2009 11:46 PM
acts_as_taggable_on_steroids e will_paginate
Num dos projetos que trabalho utilizo o plugin acts_as_taggable_on_steroids. Pela primeira vez fui fazer paginação de elementos com tags utilizando o will_paginate. O acts_as_taggable_on_steroids fornece o método de classe find_tagged_with que serve para buscar por items com uma determinada tag:
Post.find_tagged_with('rails')
E é possível fazer paginação utilizando o método paginate_tagged_with, mas o problema é que ele não funciona como deveria. Apesar de fazer a paginação funcionar corretamente, a sql que ele gera para fazer o count dos elementos não é correta. Se usado sem conditions, ele gera o número de páginas considerando todos os elementos da base. Eu escrevi o seguinte monkey patch, que coloquei no /lib do projeto:
module ActiveRecord
module Acts
module Taggable
module SingletonMethods
def paginate_tagged_with(tags, args = {})
options = find_options_for_find_tagged_with(tags, :match_all => true)
options.merge!(args)
paginate(options.merge(:count => { :select => options[:select].gsub("#{table_name}.*", "#{table_name}.id") }))
end
end
end
end
end
Para usar basta colocar no seu controller algo como:
@posts = Post.paginate_tagged_with(params[:tag_id], :page => params[:page] || 1)
Também escrevi uma spec para testar o funcionamento. Ela só faz sentido dentro do contexto do meu projeto, mas basta você modificar as fixtures, os modelos, etc, de acordo com seu projeto.
describe Post do
it "should return the correct total_pages to will_paginate" do
post = posts(:blog_post)
5.times do
new_post = BlogPost.new(post.attributes)
new_post.tag_list = 'global'
new_post.save
end
paginator = BlogPost.paginate_tagged_with('global', :page => 1, :per_page => 2)
paginator.total_entries.should == 6
paginator.total_pages.should == 3
end
end
2 comentários : 21.01.2009 12:09 AM
Empreendedorismo on Rails no Encontro de TI
Sairam os vídeos da minha apresentação no Encontro de TI. A palestra foi gentilmente cedida pelo Vinícius, originalmente apresentada no Rails Summit 2008.
4 comentários : 16.12.2008 09:10 PM
Como vocês fazem o "describe" das suas specs?
Isso pra mim sempre foi uma dúvida ao usar o rspec. Realmente não há forma correta. É uma opção pessoal no caso de um projeto particular ou de decisão em conjunto no caso de um projeto onde vários desenvolvedores participam.
Mas o fato é que eu nunca adotei nenhum padrão para isso. É uma coisa que tem me deixado um pouco incomodado. Em alguns modelos sigo o padrão de um describe para cada método, em outros segui padrões ligeiramente diferentes, como por exemplo testes relacionados a attributos em um describe, relacionamentos em outro describe e assim por diante. Ou seja, não há padrão. Há tempos atrás ouvi uma frase que nunca esqueci:
Quando dois padrões existem, não há padrão.
No Lucidus usávamos Test::Unit(quando o projeto começou o rspec ainda era muito pouco difundido) então o “padrão” para nós era pelo menos colocar os testes relativos juntos. Então os testes relativos a um mesmo método normalmente estavam juntos, em um “bloco”, um abaixo do outro. O rspec nos permite um pouco mais de organização. Mas fazer essa organização extra através dos describes proporciona algum benefício?
Então seguindo a idéia… nós precisamos discutir testes.
Qual opnião de vocês? Como vocês organizam seus describes? E o que vocês escrevem nele?
3 comentários : 28.11.2008 03:18 AM
Um "setup" global para todas as suas specs
Ficou bem difundido no rspec a forma em como fazer o setup antes das specs executarem, assim como existe também no Test::Unit.
describe Act do
before(:each) do
(...)
end
it "should have many persons associated" do
(...)
end
end
Eu estava precisando fazer o setup para todas as minhas specs (do planeta :), então descobri uma forma que está mal documentada(pelo menos eu não achei bom), mas é super simples de usar. É só editar o spec/spec_helper.rb e adicionar dentro do bloco:
Spec::Runner.configure do |config|
(...)
end
O seguinte:
config.before(:each) do
your_global_setup_here
end
Você também pode executar o setup somente para os controllers, models ou helpers assim:
config.before(:each, :behaviour_type => :controller) do
your_global_controllers_setup_here
end
Ou
config.before(:each, :behaviour_type => :helper) do
your_global_helpers_setup_here
end
Ou
config.before(:each, :behaviour_type => :model) do
your_global_models_setup_here
end
Como se chama o “setup” no bdd? É setup mesmo?
4 comentários : 27.11.2008 02:50 AM
Fazendo o will_paginate traduzir o "Previous" e "Next"
Eu precisei traduzir para várias línguas os links de “Previous” e “Next” do will_paginate, mas não seria nada dry passar os parâmetros em todas as chamadas a will_paginate(). Outra solução seria criar um método helper que faria a chamada ao will_paginate() passando os parâmetros e nas minhas views eu chamaria esse helper no lugar de chamar will_paginate(). O problema é que sempre que fosse criada uma nova tela com paginação a pessoa teria que lembrar de chamar o método helper e não chamar o will_paginate() diretamente.
Então pra mim a melhor solução foi criar uma extensão, que deixa tudo transparente. Eu coloquei em /lib dentro do projeto rails.
module WillPaginate
module ViewHelpers
def will_paginate_with_translate(collection = nil, options = {})
options, collection = collection, nil if collection.is_a? Hash
options.merge!(:prev_label => _("« Previous"), :next_label => _("Next »"))
if collection
will_paginate_without_translate(collection, options)
else
will_paginate_without_translate(options)
end
end
alias_method_chain :will_paginate, :translate
end
end
O método _() que é chamado é o método que faz a tradução no plugin de localização que estou utilizando, você deve alterar para a forma como você faz a localização no seu projeto. Também criei as specs para assegurar o funcionamento:
require File.dirname(__FILE__) + '/../spec_helper'
describe WillPaginate::ViewHelpers do
describe "will_paginate translations" do
before(:each) do
@expected = 'paginate_mock'
@model = mock('model-mock')
@translation_options = {:prev_label => _("« Previous"), :next_label => _("Next »")}
@options = {:option1 => '1', :option2 => '2', :next_label => 'next-fake'}
end
it "should will_paginate only with translations" do
helper.should_receive(:will_paginate_without_translate).with(@translation_options).and_return(@expected)
helper.will_paginate == @expected
end
it "should will_paginate with @model parameter" do
helper.should_receive(:will_paginate_without_translate).with(@model, @translation_options).and_return(@expected)
helper.will_paginate(@model) == @expected
end
it "should will_paginate with @model parameter and options" do
helper.should_receive(:will_paginate_without_translate).with(@model, @options.merge(@translation_options)).and_return(@expected)
helper.will_paginate(@model, @options) == @expected
end
end
end
Espero que seja útil para alguém ;)
4 comentários : 24.11.2008 12:52 PM
Rails Summit dia 16: Obie Fernandez
Tudo que tenho para falar é como trabalhamos com os principios Ágeis. Eu começei em XP em 2000 e trabalhei com isso por muito anos… já são 10 anos de experiência. Nós buscamos a melhor maneira de desenvolver software. Começando sobre princípios e iterações sobre processos e ferramentas. Isso nos diz que a coisa deve estar em busca das pessoas. Como a programação em par impacta na produtividade? Isso parece contra a intuição, mas duas pessoas trabalhando em um computador pode ser mais produtivo que duas pessoas trabalhando em dois computadores. A melhoria do design no desenvolvimento em par é melhorado, além de ser mais gostoso. Pair programming não é uma coisa natural pois não é naturalmente usado em grandes empresas, mas é preciso aprender… e leva um certo tempo.
Eu acho muito importante ter dois teclados e dois mouses pois dessa maneira, uma só pessoa que tenha um perfil dominante não trabalha sozinha. Um dos princípios que melhora a produtividade é a revisão de código automática. Ao trabalhar em par isso é natural. Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.
É comum entre nós desenvolvedores, muitos de vocês mais inteligentes do que eu trabalham muito bem. Então dizem que demoram uma hora para realizar o trabalho, mas ficam horas escrevendo no blog e no twitter, fazem o trabalho em 5 minutos e depois vão para o almoço. O pair programming elimina isso. Ele te dá muita produtividade. Para as pessoas farerem pares é preciso contratá-las. Quando eu contrato pessoas para a minha empresa eu faço um post no meu blog e espero as respostas. Você diz as suas habilidades e é convidado a trabalhar por uma semana para nós sabermos se você é bom de verdade fazendo pair programming num projeto de verdade. Então nós contratamos as pessoas sem entrevistas, mas com elas trabalhando num projeto real por uma semana. Só por que alguém vai bem numa entrevista não tem relação em como ela é no dia-a-dia do trabalho. Em times pequenos é mais fácil de manter a felicidade de todas as pessoas. Times de 2 a 4 pessoas são boas opções. Além disso vocês podem ter problemas de comunicação.
Mais um principio que se pode utilizar ao ter um time de 2 a 4 pessoas é ter um time auto-organizado. Na nossa empresa a gente não tem chefes. Todos os times são auto-gerenciados. Pois se você tem um time desse tamanho de apenas pessoas boas e você tem um lema “todo mundo junto” as coisas simplesmente funcionam.
Software funcionando em contrário a uma extensiva documentação. Uma maneira de trabalhar desse jeito é usando rspec, nós somos fãs de rspec. É uma ferramenta tão eficiente, ela não somente ajuda você a trabalhar com o software, mas também para gerar uma documentação, que nós entregamos para o nosso cliente. Isso com certeza agrega valor ao nosso trabalho.
Eu me importo em ser real e essa uma razão pelo o qual eu estou envolvido por tanto tempo com Rails. Nós participamos do Rails Ramble de 2007, isso foi antes da formação do Rails Rocket, e isso mostrou pra gente que é possivel com Rails fazer um trabalho muito grande com pouco tempo. Foi muito bom trabalhar com essas restrições, pois na nossa área é comum o tamanho de um projeto expandir para caber no tempo total disponível para o desenvolvimento.
Nós trabalhamos com um conceito chamado 3-2-1. Que significa colocar um software no ar em 3 dias, onde temos 4 desenvolvedores, 2 da nossa equipe e mais 2 que chamamos para uma semana de trabalho.
Colaboração do cliente em frente a negociação de contratos. Isso tudo tem relação com transparência em relação ao cliente. Isso leva confiança ao seu cliente. Nós gostamos dos clientes com o qual trabalhamos.
Uma coisa importante é que você precisa ter um designer dentro da equipe que saiba fazer todo o visual do nosso projeto. Pois sem um projeto visual acabado, nós não temos o que mostrar para o nosso cliente. É bom ver exatamente como vai ficar e eu posso construir isso em 3 dias se você me mostrar como vai ficar.
Por outro lado, quando já temos um design, não temos muito o que divergir da maioria é que nós gostamos de user stories, que para nós significam a aceitação do cliente. Nós trabalhamos com cartões e com projeções para atividades que duram de 0 até 8 pontos de desenvolvimento. Com isso nós medimos o desenvolvimento de nosso equipe e quantos pontos podemos fazer por semanas. Na nossa equipe é comum fazer algo em torno de 25 pontos por semana. Em 0 pontos nós temos coisas que duram apenas alguns minutos e em 4 pontos nós temos coisas que duram uma semana.
Antes nós perdíamos muito tempo com negociação de contrato. Então nós desenvolvemos um documento, que serve como nosso contrato, que não exije que o cliente nos pague caso ele não esteja satisfeito. Esse contrato tem um termo especial que diz que ele não pode te processar por mais dinheiro que ele iria te pagar. O nosso contrato também estabelece que nós podemos contribuir com o mundo opensource com o código desenvolvido para eles, mas só as coisas que não são específicas do cliente, como plugins e gems que você desenvolveu para trabalhar naquele projeto.
E a última parte do manifesto ágil é responder a mudanças em vez de seguir um plano. Nós usamos um serviço chamado pivot tracker e ele é muito bom pois ele nos mostra muitas informaçõe sobre o nosso projeto, incluindo gráficos de burndown entre outros. A stand up meeting é outra coisa essencial para nós sobre como anda o nosso projeto e nos ajuda a dar mais uma previsão sobre quanto tempo esse projeto ainda vai demorar. Todos falam sobre o que fizeram ontem, o que farão hoje e sobre o que está atrapalhando o trabalho. Quando estamos com mais pessoas, como nós que já estamos com 20 pessoas, temos que mudar um pouco a dinamica do standup meeting, mas a essencial é a mesma.
Tenho mais uma coisa para falar, que coloquei no final, que é a parte mais importante do Hashrocker, a nossa empresa, é que nós achamos que a coisa mais importante é se divertir no trabalho. Sem diversão não há produção. Nós fazemos algumas coisas em conjunto para diversão.
E nós bebemos bastante para nos divertir e pulamos na piscina quando todos estão bêbados!
2 comentários : 16.10.2008 08:37 PM
Rails Summit dia 16: Phillippe Hanrigou
Existem diversos problemas com os testes do selenium. São naturalmente lentos, assim como qualquer tipo de teste de integração. Eles rodam no navegador, que são coisas instáveis, bugados. E ainda colocam pessoas poucos experientes para escrever os testes do selenium, o que é um problema. Tem que ser os melhores para fazer essa tarefa! Mas se é tão dificil, por que fazer?
E quanto mais javascript se usa, mais devem haver testes. Se você usa muito javascript a sua chance de ter algo que não funciona em todos os browsers é alta. E se você não suporta todas as plataformas, você estará perdendo dinheiro caso não suporte todas. Sobretudo na comunidade Rails. Então é por isso que temos que automatizar esse tipo de testes. E essas são coisas que tem que ser repetidas diversas vezes… então não são coisas que os humanos tem que fazer. A coisa mais fundamental sobre esses testes e a comunidade de Rails está usando esse tipo de ferramente, mas tem muitas coisas que podemos apredender dos mais antigos. Coisa que podemos aprender de antigos programadores XP, é que testes de aceitação são muito importantes. Pois os testes de aceitação dão poder ao cliente. Você precisa da aceitação para fazer o código correto, do ponto de vista do cliente. Os unit testes server para garantir que os pequenos pedaços funcionam, mas os testes de aceitação server para garantir que tudo funciona junto. O teste de aceitação é tão importante no desenvolvimento que ela não é considerada completa até que ela passe numa suite de aceitação. Uma suite de aceitação te gera confiança.
Depois da era de ouro, vieram os bárbaros! Os bárbaros são os browser, que impediram a realização de muitos testes de aceitação. Por sorte hoje temos o selenium.
Quando um teste falha, temos que investigar para descobrir onde está o problema. Então você tem que rodar isso na sua máquina e com sorte o problema também ocorrerá na sua máquina. A melhor forma de resolver o problema com mais facilidade é capturar a maior quantidade de informações no campos de testes: na máquina que rodou o teste, no browser e etc.
Agora a parte boa para diminuir o tempo de testes do selenium é que desenvolvemos o selenium-grid, que permite que diversos testes do selenium sejam paralelizados, inclusive entra diferentes máquinas de diferentes poderes de processamento. Um dos problemas, assim quando você coloca muitos fios de energia muitos juntos, é que você tem que garantir que um teste não irá interferir nos outros. Garantir por exemplo que as coisas irão rodar em stacks de Rails diferentes.
Uma coisa boa a fazer é deixar de fazer login como um teste no selenium, mas inserir diretamente um cookie no navegador e resetar a base de dados diretamente pelo teste do selenium. Isso é muito mais rápido.
A questão das fixtures. Testar com dados randomicos é complicado, pois há muitos efeitos colaterais. Testar usando fixtures fixas com grandes aplicações pode tornar a manutenção das fixtures muito dificil. Uma das soluções que podemos usar é criar os dados usados nos testes diretamente nos próprios testes, sem o uso de fixtures. Mas isso também é complicado, pois pode dar trabalho preencher objetos complexos. Uma solução plausível são os Object Mother. São como templates de objetos instanciados padrões, onde você passa parametros apenas para sobrescrever os valores do objeto que você quer que sejam diferentes do default. Existem diversas maneiras de fazer isso e há muita documentação na internet sobre o assunto.
Eu queria que vocês saissem daqui sem esquecer: não virem as costas para os testes de aceitação.
0 comentários : 16.10.2008 05:30 PM
