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 https://github.com/rspec/rspec-rails, right?

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

Best,