Difference between rake test:units and individually running ruby -I test test/unit/something_test.rb ?

Here's my issue: running ruby -I test test/unit/something_test.rb for each of my unit tests works perfectly. However, running rake test:units brings errors in all of them - some object becomes nil for some reason.

Why might this be happening?

Specifics: the object that is successfully not nil when I run the unit tests one-by-one but becomes nil when I do rake test:units is defined like this...

klass = self.name.gsub(/Test$/, "").constantize instance = klass.first

...and I'm sure that my test db is populated whenever I run my tests...

daze wrote in post #970203:

Here's my issue: running ruby -I test test/unit/something_test.rb for each of my unit tests works perfectly. However, running rake test:units brings errors in all of them - some object becomes nil for some reason.

And what object is that?

Why might this be happening?

Specifics: the object that is successfully not nil when I run the unit tests one-by-one but becomes nil when I do rake test:units is defined like this...

klass = self.name.gsub(/Test$/, "").constantize instance = klass.first

Let's see your error messages. But why the heck are you defining an object like this anyway? What are you trying to achieve?

...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.

Best,

You could use ruby-debug to break into the test at the point of failure and inspect the data and see what is going on. If you have not used ruby-debug have a look at the Rails Guide on debugging to see how.

Colin

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   context "acting as a list" do     setup do # DON'T DO THIS???       #@instance = klass.all[0]     end

    should "have a position column" do       instance = klass.first       assert_not_nil instance.position, :message => "If you see me, check out the POSITION."     end

    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

  end end

My error messages just show this:

daze wrote in post #970337:

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. :slight_smile:

Best,

Oh whoa okay thanks. I better make some changes now... :confused:

Can I use Shoulda w/ Rspec, or do I just use one over the other? And I should use this one https://github.com/rspec/rspec-rails, right?

Please quote when replying.

daze wrote in post #970358:

Oh whoa okay thanks. I better make some changes now... :confused:

Can I use Shoulda w/ Rspec, or do I just use one over the other?

I understand Shoulda is usable with RSpec. I've never actually used Shoulda on any of my projects, though. (And you *should* be able to do what you're doing with Shoulda and Test::Unit.)

And I should use this one GitHub - rspec/rspec-rails: RSpec for Rails 5+, right?

rspec-rails works with RSpec to provide some Rails-specific features. Please see http://rspec.info for more information.

Best,