daze wrote in post #970337: > On Dec 22, 10:38pm, Marnen Laibow-Koser <[email protected]> wrote: > >> Let's see your error messages. But why the heck are you defining an >> object like this anyway? What are you trying to achieve? > > I'm trying to get a test for acts_as_list working. I've defined a > method in test_helper that I use in my unit tests: > > # tests acts as list and default_scope :order => 'position' > def self.should_act_as_list(options = {}) > klass = self.name.gsub(/Test$/, "").constantize # converts string > to class
Nonononono. Don't do it that way. With RSpec, you'd write a custom matcher class; I don't know if the same thing is done with Shoulda. But you're getting too complex here and asking for trouble. Please read about how custom should_* methods are supposed to be written. > context "acting as a list" do > setup do # DON'T DO THIS??? > #...@instance = klass.all[0] > end What on earth is that for? > > should "have a position column" do > instance = klass.first > assert_not_nil instance.position, :message => "If you see me, > check > out the POSITION." > end That won't actually do what you want -- it will just make sure that position is not nil. You'd have to check the columns array or use respond_to? to do what you're trying for here. > > should "move objects correctly" do > instance = klass.first > instance.move_to_bottom > assert_equal klass.all[-1], instance > instance.move_higher > assert_equal klass.all[-2], instance > instance.move_to_top > assert_equal klass.first, instance > instance.move_lower > assert_equal klass.all[1], instance > end Probably not necessary -- you're testing acts_as_list here, which is presumably already well tested. You are really doing things the hard way here. Learn a bit more about Ruby's metaprogramming... [...] >>>> ...and I'm sure that my test db is populated whenever I run my tests... > >> You shouldn't have to be sure of that beforehand; rather, you should be >> using factories to create records for tests on the fly. > > I want my development and test dbs to be the same, No you don't. You want the *schemas* to be the same, but you want only specially crafted test data in your test DB. > so I thought using > the seeds.rb file - which in my case uses Factories Your seeds file probably should not be using factories. > - in conjunction > with rake db:seed RAILS_ENV=test would be the best way. There are > some things I want to have set names for, like sections - they'll > always be Sports, News, etc. Other things like Articles, though, I > generate in the seeds file en masse. > Is my methodology totally wrong? Yes. > Should I be testing acts_as_list's > functionality in a totally different way? That's a separate question from seeds. > > I mean, are you saying I should create records in the "setup" method > for each unit test rather than populate the db with that rake db:seed > RAILS_ENV=test command? Yes. Seeding the test database is never a good idea (this is why fixtures are dangerous), because it becomes difficult to make sure your tests don't share state, and also because it becomes difficult to keep track of the assumptions you're making. Use factories to create only the actual records you need for each test case (generally less than 10). And do check out RSpec when you get a chance. :) Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
