开发者

validates_uniqueness_of failing with tests, machinist

I have a validates_uniqueness_of validation on my model:

#SwimMeetRelayEvent.rb
validates_uniqueness_of :event_number_digit, :scope => [:swim_meet_id, :event_number_alpha]
validates_uniqueness_of :event_number_alpha, :scope => [:swim_meet_id, :event_number_digit]

#blueprint.rb
  SwimMeetRelayEvent.blueprint do
    swim_meet           { SwimMeet.make }
    athlete_min_age     { rand(4) + 8 }
    athlete_max_age     { rand(4) + 12 }
    athlete_gender      { Sham.gender }
    distance            { ['25', '50', '100'].sort_by { rand }.first }
    stroke              { [6, 7].sort_by {rand}.first }
    event_number_digit  { rand(100) + 1}
    event_number_alpha  { ('A'..'Z').to_a.sort_by {rand}.first}
  end

I'm using Machinist and the above validation fails any time I run a test with

SwimMeetRelayEvent.make

I'm just making 1 'Event' in my tests and have tried different values for event_number_digit, event_number_alpha, with no luck. Any ideas?

# trace
  1) Error:
test_something(Manage::SwimRelayTeamsHelperTest):
ActiveRecord::RecordInvalid: Validation failed: Event number digit has already been taken, Event number alpha has already been taken, Event number Event Number is already take
n
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/validations.rb:1102:in `save_with_validation!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/dirty.rb:87:in `save_with_dirty!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/transactions.rb:200:in `block (2 levels) in save_with_transactions!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/transactions.rb:182:in `transaction'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/transactions.rb:200:in `block in save_with_transactions!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/transactions.rb:208:in `rollback_active_record_state!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/activerecord-2.3.11/lib/active_record/transactions.rb:200:in `save_with_transactions!'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/machinist-1.0.6/lib/machinist/active_record.rb:55:in `make'
    /Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@swimtopia/gems/machinist_callbacks-0.2.0/lib/machinist_callbacks.rb:51:in `block (2 levels) in <top (required)>'
    test/unit/helpers/manage/swim_relay_teams_helper_test.rb:5:in `block in <class:SwimRelayTeamsHelperTest>'

59 tests, 142 assertions, 0 failures, 1 errors, 0 skips

Test run options: --seed 62766
rake aborted!
Command failed with status (1): [/Users/dwalseth/.rvm/rubies/ruby-1.9.2-p13...]
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:995:in `block in sh'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1010:in `call'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1010:in `sh'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1094:in `sh'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1029:in `ruby'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1094:in `ruby'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake/testtask.rb:117:in `block (2 levels) in define'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1112:in `verbose'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake/testtask.rb:102:in `block in define'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:636:in `block in execute'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:597:in `block in invoke_with_call_chain'
/Users/dwalseth/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2029:in `block (2 levels) in top_level'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2029:in `block in top_level'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2001:in `block in run'
/Users/dwalseth/.rvm/gems/ruby-开发者_开发问答1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/gems/rake-0.8.7/bin/rake:31:in `<top (required)>'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/bin/rake:19:in `load'
/Users/dwalseth/.rvm/gems/ruby-1.9.2-p136@global/bin/rake:19:in `<main>'


I would start by verifying that the test database is being purged between test runs. You can run:

rake db:test:prepare

Which (by default) will drop and recreate the test database to match the development database schema -- should be blank at that point. If you test against a fresh db after running this, do you still run into problems?

Is it critical that they be in random order? You could define a sham that generates them sequentially:

Sham.define do
  event_number_digit { |index| (index % 100) + 1 }
  event_number_alpha { |index| ('A'..'Z').to_a[index] }
end

Then use the shams in your blueprint. That way, you could be guaranteed that you could make 26 in a row before violating uniqueness constraints. When you generate at random, you're at risk of random failures at any point.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜