Getting fixtures to work without Rails

[Vassilis Rizopoulos]

Yes, this is ActiveRecord without Rails again.
Specifically testing with fixtures.
I'm stuck making them work and I know exactly where the code is checking
out and leaving me in the dark.

Now, the following will not load the fixtures and I want to know why.

require 'rubygems'
require 'active_record'
require 'active_record/fixtures'
require 'test/unit'

class Schema<ActiveRecord::Migration
def self.up
create_table :entries do |t|
t.column :txt, :string
end
end
end

class Entry<ActiveRecord::Base
end

class TestFixture<Test::Unit::TestCase
ActiveRecord::Base.establish_connectionadapter =>
"sqlite3",:database =>":memory:")
Schema.up
fixture_path=File.join(File.dirname(__FILE__))
use_instantiated_fixtures=true
fixtures :entries

def test_fixtures
assert_equal(2,Entry.findall).size)
end
end


Use the following in an entries.yml:

new_entry:
txt: "new entry"

old_entry:
txt: "old entry"


I'm using active record 1.15.3. I followed the call chain all the way to
a check in Test::Unit::testCase#setup_with_fixtures.
The first line in that method is

return unless defined?(ActiveRecord::Base) &&
!ActiveRecord::Base.configurations.blank?

and the configurations are ofcourse blank

So what am I missing? Obviously I need to recreate some more of that
Rails magic.
Cheers,
V.-

 

[Gregory Brown]

So what am I missing? Obviously I need to recreate some more of that
Rails magic.

This doesn't answer your question, but unless you've already created a
ton of fixtures, consider not using them at all. They suck in Rails
and probably will suck even more outside of Rails. :-/

 

[Vassilis Rizopoulos]

This doesn't answer your question, but unless you've already created a
ton of fixtures, consider not using them at all. They suck in Rails
and probably will suck even more outside of Rails. :-/

OK, let us discuss this, cause I am at the point where I need data in
the database (to get ruport in gear ) and I'm looking for a practical
way to DRY such sets of data.
Fixtures at the moment give me the ability to centrally manage my data
(and if I could get them working) not write much more code.
Note that at this point I am talking unit testing and I want to be able
to run my tests with and without using rake (just a perk of mine).
What would be a viable alternative for adding test data to an AR database?
Cheers,
V.-

 

[Giles Bowkett]

So what am I missing? Obviously I need to recreate some more of that

This doesn't answer your question, but unless you've already created a
ton of fixtures, consider not using them at all. They suck in Rails
and probably will suck even more outside of Rails. :-/

+1 on avoiding fixtures. Fixtures are notoriously fragile. They handle
simple cases very quickly and nicely in that respect but in terms of
more complicated setups everything kind of goes boom.

What would be a viable alternative for adding test data to an AR database?

I'm honestly not certain, but I believe the ideal answer here is to
use Mocha and Stubba to create mocks and stubs. In practice I'm afraid
I've sometimes resorted to layer after layer of brittle,
interdependent fixtures.

The weird thing is there's also RSpec, which I believe is ultimately
preferable to Test::Unit for its alternate terminology, but which I
haven't yet tested in practice. Anyway, RSpec uses mocks and stubs a
lot, but doesn't use Mocha or Stubba IIRC. I don't know why not.

 

[Gregory Brown]

What would be a viable alternative for adding test data to an AR database?

Giles mentioned mocking which is certainly fine.

These posts might be helpful:
http://blog.floehopper.org/articles/2006/06/27/rails-fixtures-help-or-hindrance
http://blog.floehopper.org/articles/2006/08/10/fed-up-with-rails-fixtures-part-one
http://blog.floehopper.org/articles/2006/08/14/fed-up-with-rails-fixtures-part-two

In the context of Rails, I just do regular Model.create statements and
let the database cleanup after itself. In stuff outside of rails, I
some kind of hacky stuff that I can't really recommend. (Usually
manually blowing up DBs or calling destroy_all in cleanup)

I'd be interested in a safe way to do this too, although if you use
mocks, you may not need it at all.

Also, many of your tests won't require the data to be in the database.
Sometimes just doing @my_record = Model.new and then testing methods
and things like that does the trick (so long as they don't need to be
saved to work).

 

[Vassilis Rizopoulos]

These posts might be helpful:
http://blog.floehopper.org/articles/2006/06/27/rails-fixtures-help-or-hindrance

http://blog.floehopper.org/articles/2006/08/10/fed-up-with-rails-fixtures-part-one

http://blog.floehopper.org/articles/2006/08/14/fed-up-with-rails-fixtures-part-two


In the context of Rails, I just do regular Model.create statements and
let the database cleanup after itself. In stuff outside of rails, I
some kind of hacky stuff that I can't really recommend. (Usually
manually blowing up DBs or calling destroy_all in cleanup)

I'd be interested in a safe way to do this too, although if you use
mocks, you may not need it at all.

Also, many of your tests won't require the data to be in the database.
Sometimes just doing @my_record = Model.new and then testing methods
and things like that does the trick (so long as they don't need to be
saved to work).

I agree that many tests do not need data in the database. But let me
narrow the scope a bit:
rutema (shameless plug: http://patir.rubyforge.org/rutema/) essentially
lets you execute tests (automated or not) - we're talking about testing
a test tool, funny that!
All the results end up in a database. It's a straightforward affair
(still - you never know). The schema is simple, but we're talking about
*a lot* of records.
The idea is to leverage all that accumulated data and do something
usefull such as detect intermitent failures, spot problematic test
scenarios, find which tests where ran against specific software versions
etc. and then produce reports on it (yes, yes, ruport is a perfect fit)
Essentially I am developing the various views on the data using my tests
and I want data to do this.
The easiest way is(was) to create that data, put it in the database and
start doing different queries on them.
I've got my reserves about mocking for this purpose.
Fixtures present an easy way to load and unload the database and being
lazy I thought to do it once and use that same data for feeding other
tests as well.
Having said that I find the whole fixtures criticism valid and I agree
on most (if not all) points.
I guess going with the model-in-memory approach(
Run.new({:all_the_data=>like_this}) is the cleaner solution in this
case. Yep, the more I think about it the more I like it
Now to get those tests kitted up!
Cheers,
V.-

P.S. out of academic curiosity I would still like to know why that
fixture using code is not working.