Desenvolvimento Ágil - Blog da Improve It: Como Testar parte 1 - Models

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.

"Como Testar parte 1 - Models" by Guilherme

Thu, 22 Jan 2009 17:51:21 -0200

Parabéns, excelente artigo ! :D show de bola! Podia ter mais.. haha =D

"Como Testar parte 1 - Models" by Rafael Quintana

Tue, 13 Jan 2009 12:43:57 -0200

Fala pessoal,

O ActiveRecord é muito bom mesmo, inclusive tem inspirando outros projetos em outras plataformas, como o iPhone. Isso mesmo, existe ActiveRecord para iPhone e é muito parecido com o de Ruby on Rails, só que é em Objective C. Escrevi um pouco sobre ele nesse link:

http://www.mobits.com.br/2009/1/6/mapeamento-objeto-relacional-no-iphone

Abraços e sucesso a Improve It!

"Como Testar parte 1 - Models" by Rodrigo Reginato

Sat, 20 Dec 2008 12:08:02 -0200

legal o reflect_on_association, curti muito!! valew

"Como Testar parte 1 - Models" by elomarns

Tue, 18 Nov 2008 14:54:00 -0200

Sei que esse post já é meio antigo (22 dias na Web é uma eternidade), mas só pude ler agora, e não posso deixar de dizer que ele foi excelente.

O artigo mostrou exemplos bem claros, mesmo para quem não sabe muito sobre testes, como eu, que sei bem pouco sobre RSpec e posso dizer que já aprendi a escrever alguns testes básicos com ele. A maior prova disso é que eu escrevi o teste do named scope com RSpec logo após ver o mesmo teste com Test::Unit, e vi que escrevi exatamente como indicado no artigo.

Além disso, aprendi alguns recursos do Rails interessantes, como o reflect_on_association e o proxy_options, sendo que esse último eu já tinha visto, mas não tinha parado pra ver como funciona.

Em relação a filosofias ao elaborar os testes, eu sou mais voltado a testar o comportamento, por isso estranhei um pouco o teste do named scope, mas acho que isso varia conforme as preferências pessoais e com a aplicação em questão, não existindo algo que possa ser considerado como o jeito definitivamente certo.

Sobre a questão de uma asserção por teste, apesar de estranhar inicialmente, me parece uma boa idéia, principalmente depois dos argumentos apresentados.

Por fim, não tem como deixar de mencionar os comentários de altíssimo nível desse post. Graças a eles e aos links postados eu aprendi um monte de outras coisas bem interessantes.

Enfim, parabéns pela excelente idéia de publicar essa série de posts.

"Como Testar parte 1 - Models" by Thiago

Thu, 06 Nov 2008 16:57:00 -0200

Parabéns pelo artigo e continue com a série, está sendo de grande valia.

Me tira uma dúvida, é realmente interessante fazer testes que checam se a mensagem de erro é igual a uma string? E se sobreescreverem a mensagem de erro da validação, ou se utilizarem internacionalização?

"Como Testar parte 1 - Models" by Ramon Soares

Thu, 06 Nov 2008 11:10:12 -0200

Muito bom artigo.

Mas tem um erro:

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)

n são permitidos domínios com _ (ihatethemicrosoft.com e/ou ilove_my_mac.com). axo que uma melhor regex pra valida email seria:

/\A([^@\s]+)@((?:[-a-z0-9]+.)+[a-z]{2,})\Z/i

"Como Testar parte 1 - Models" by Ricardo Almeida

Thu, 30 Oct 2008 23:59:01 -0200

Muito Bom Tapajós! Parabéns.

Você está motivando bastante gente a estudar mais sobre testes.

Eu também tinha escutado sua entrevista no RailsBox e achei que foi uma verdadeira aula.

Escrevi alguns posts no meu blog relativos a testes, mas não foi nada tão prático como esse excelentente post.

Valeu!

"Como Testar parte 1 - Models" by Lucas de Castro

Thu, 30 Oct 2008 19:13:20 -0200

Parabéns Tapajós, ótimo post!

"Como Testar parte 1 - Models" by Andressa

Wed, 29 Oct 2008 18:43:45 -0200

Ótimo post! Concordo quando dizem que é muito bom abordar este assunto, já percebi que muitas pessoas ainda não entraram de verdade no mundo dos testes.

Sobre a questão de uma assertion por teste, discuti exatamente isso com minha orientadora de um projeto de pesquisa e o que ela me disse me convenceu:

Imagine que você possui uma aplicação grande, com vários testes, sendo que para rodar todos você gasta um tempo considerável. Se há mais de uma assertion em cada teste (método) e se a primeira já falha, você não possui garantia nenhuma de que as outras assertions desse mesmo teste (método) estão corretas. Assim, se na primeira vez você corrigiu 5 falhas, na próxima vez você teria que esperar todos os testes rodarem novamente e ainda correr o risco de surgir novas falhas que já poderiam ter sido identificadas anteriormente.

Se há somente uma assertion por teste, você consegue identificar logo na primeira "rodada" todas as falhas daqueles testes e pode corrigí-las de uma vez.

Bem, me convenceu. Não se se convence a vocês, rs. E desculpe se isso for óbvio demais, rs. Estou iniciando nesse universo dos testes ainda!

Parabéns e abraços! ^^

"Como Testar parte 1 - Models" by Pedro Valentini

Tue, 28 Oct 2008 23:34:44 -0200

Legal o artigo, obrigado! Exemplos práticos são a melhor forma de aprender, ja li bastante sobre testes de software mas ainda não fazem parte do meu dia-a-dia. Isso vai ser um incentivo, vou usar no Sociare =] Abs, Pedro

"Como Testar parte 1 - Models" by Lucas Húngaro

Tue, 28 Oct 2008 11:04:22 -0200

Tapajós, dá pra você substituir todas as fixtures por factories (uso factory_girl pra isso) e manter os testes limpos.

Manda bala nos posts porque, como eu disse anteriormente, pouco se fala sobre isso na comunidade.

"Como Testar parte 1 - Models" by Carlos Brando

Mon, 27 Oct 2008 18:59:01 -0200

Eu confesso que o único motivo de usar Shoulda ao invés de RSpec são as macros do Sholda.

Mas eu sou um zé mané quando se fala de testes.

Por favor, continue com esta série... tem muita coisa ainda que precisa ser dita.

"Como Testar parte 1 - Models" by Vinícius Manhães Teles

Mon, 27 Oct 2008 18:32:19 -0200

Bom trabalho, Tapa!!! :)

Não pára! Não pára! Não pára! Não pára!

Grande abraço, Vinícius.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 18:26:22 -0200

Ronaldo, esse é o espirito, fomentar discussões e levar ao aprendizado.

Obrigado pelo seu feedback.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 18:22:14 -0200

Tim, dá para fazer isso que você citou em RSpec usando o Skinny Spec.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 18:21:16 -0200

Carlos, eu só conheço um desses projetos que é o Skinny Spec. Tenho usado ele em uns projetos lá na Surgeworks e no geral estou satisfeito.

Algumas coisas eu mesmo implemento no meu spec_helper e depois reuso.

Por questões de didática preferi não cita-los pois queria mostrar como testar mesmo. Mostrar como as coisas funcionam ao invés de mostrar apenas chamadas que ninguém sabe como funcionam.

Para nós que já temos experiência no assunto meus testes podem parecer bem tolos, mas a idéia desse post é ajudar quem conhece muito pouco de testes.

Acho que eu não precisaria escrever um artigo de testes voltado aos experts em testes pois com certeza sou eu que tenho que aprender com eles.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 18:13:03 -0200

Lucas, seu comentário não foi moderado. Pode ser que o nosso sistema de blog tenha marcado como spam e alguém foi lá e marcou como confiavel, pois está aparecendo aqui.

Não vou te levar a mal, é discutindo que se aprende. Não existe forma melhor de aprender do que tentar ensinar algo para alguém. Tinha certeza que iniciando essa série eu ia começar a aprender várias coisas.

Tudo que eu faço com RSpec eu posso fazer com o Shoulda e realmente tem muito teste tosco com RSpec.

Na verdade o que me faz gostar mais do RSpec é que ele é focado em comportamento, sua sintaxe foi criada para isso e cria meio que uma implicação implícita.

Na minha opinião são visões diferentes. Mas veja bem, eu prefiro o RSpec mas isso não quer dizer que um seja melhor ou pior do que o outro. Indo mais além, não quer dizer que "BDD" é RSpec e Shoulda "TDD". Acho que nisso nos concordamos. Certo?

Claro que nisso tudo entra a questão de gosto e de opiniões pessoais.

Com relação ao meu teste de named_scope eu concordo com você que ele não testa comportamento só que eu prefiri fazer dessa forma para não usar fixtures e além disso eu queria mostrar o proxy.

Eu não gosto de usar fixtures para esse tipo de teste mesmo que eu precise sacrificar um pouco o teste de comportamento.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 17:55:10 -0200

Akita, eu tenho usado o "Factory Girl" e estou gostando. O outro eu nunca usei.

Pretendo escrever só sobre o "Factory Girl". Aguarde e confie! :-)

"Como Testar parte 1 - Models" by Ronaldo Ferraz

Mon, 27 Oct 2008 14:24:57 -0200

Elomar, sobre a questão de fixtures em testes unitários, existem benefícios e problemas. Fixtures podem tornar os seus testes unitários mais quebradiços, mas podem também torná-los mais reais. Não usar fixtures pode rapidamente levar à necessidade de testes como o de has_many acima que, embora válido em um certo sentido, está testando a declaração e não o comportamento.

Brando, sobre as macros do Shoulda, eu tendo a evitá-las em muitos aspectos justamente porque também tendem a testar declarações e não comportamento. Especialmente as que envolvem o Rails vivem sendo vítimas de discussões por essa característica. O should_be_restful é um exemplo desse, que foi removido justamente pela opacidade. Muitos das macros envolvem esse tipo de problema e não refletem o mesmo comportamento dos matchers do RSpec. Dito isso, ultimamente meus testes tem sido Shoulda + RR.

Tapajós, sobre indução de forma, tendo a discordar já que se o teste parte de arquitetura, comportamente saí naturalmente. Dito, isso, obrigado por instigar a discussão. O texto e os comentários estão se relevando bem instrutivos para a comunidade.

"Como Testar parte 1 - Models" by Tim Case

Mon, 27 Oct 2008 14:19:47 -0200

Já trabalhei com test unit e rspec muito, e eu prefiero shoulda.

olha:

shouldrequireattributes :name shouldhavemany :accounts

"Como Testar parte 1 - Models" by Carlos Brando

Mon, 27 Oct 2008 13:31:38 -0200

Você não usa Shoulda, ok, ok... mas você usa algum matcher para evitar ficar repetindo códigos nos testes com o RSpec?

Todos os testes que você fez acima seriam umas 5 linhas com Shoulda, por exemplo. Eu sei que existem projetos como o rspec-on-rails-matchers para o RSpec que fazem o mesmo. Mas a pergunta é: Você usa? Recomenda? Qual a sua opinião sobre isto?

"Como Testar parte 1 - Models" by Lucas Húngaro

Mon, 27 Oct 2008 12:18:08 -0200

É hoje hein... eu devia ter dormido direito.

Discuti = Discute

Aliás, meu primeiro comentário, onde cometi o abominável erro de escrever "casso" não apareceu. Ele foi moderado?

"Como Testar parte 1 - Models" by Lucas Húngaro

Mon, 27 Oct 2008 12:14:58 -0200

Não. :)

(Não me leve a mal, por favor. Sempre achei que temos que discutir mais sobre testes na comunidade... todo mundo fala que faz, mas ninguém comenta, discuti, passa o conhecimento etc).

O que você faz com RSpec que não faz com Shoulda, expectations e outros?

Testar o comportamento não depende do framework. Já vi muito teste bem feito, que assegura o comportamento, feito com Test::Unit e muito, mas muito mesmo, teste porco com RSpec.

"Como Testar parte 1 - Models" by Tapajós

Mon, 27 Oct 2008 12:05:22 -0200

Lucas, com certeza você pode escrever testes de comportamento com o Shoulda assim como o inverso com o RSpec.

Acredito que a estrutura do framework de teste te induz a fazer de uma forma no RSpec e de outra no Shoulda.

Será que consegui me fazer claro?

"Como Testar parte 1 - Models" by Lucas Húngaro

Mon, 27 Oct 2008 11:59:44 -0200

Tapajós disse: "Não gosto do Shoulda pois ele tenta imitar um BDD sem ser."

Cuidado, cuidado. Usar RSpec (ou Expectations, ou whatever...) não quer dizer que você faz BDD automaticamente. Isso não existe.

Nos exemplos do post mesmo, o teste do namedscope utilizando proxyoptions é um excelente exemplo de como testar estado com uma DSL feita para testar comportamento.