Forum: RSpec how to avoid tests removing data that my migrations put in?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-04 23:47
(Received via mailing list)
hi,

I have an issue in that I have some reference data my migrations run
in. However when running  "rake spec" it seems to remove the data in
the test database up front.

What do you recommend to workaround this issue?

Thanks
Greg
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-05 00:00
(Received via mailing list)
On Tue, Nov 4, 2008 at 2:45 PM, Greg Hauptmann <
greg.hauptmann.ruby@gmail.com> wrote:

>
> I have an issue in that I have some reference data my migrations run
> in. However when running  "rake spec" it seems to remove the data in
> the test database up front.
>
> What do you recommend to workaround this issue?
>

Don't do that. :) At least, that's my opinion. Depending on database
contents for testing is a brittle road to hoe. As I just finished
saying, I
like my test database to be clean and identical in schema to my
development
database. 'rake spec' does that.

Without knowing your situation exactly, I would suggest either mocking
out
calls that you expect to deliver the prepopulated data, creating that
data
in your specs as needed, writing fixtures that load the data in, and/or
examining whether that data is really necessary for testing.

///ark
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-05 00:19
(Received via mailing list)
"Greg Hauptmann" <greg.hauptmann.ruby@gmail.com> writes:

> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

You should probably create it in a before block, or if the reference
data is always going to be the same, you'll want to insert it into the
db BEFORE the test transactions start.  That will require a bit of
work...clear out all the tables and insert the data, that way when
transactions get rolled back you're back at the db with reference data.
I'm not quite sure how to do that though.  Is there a before(:suite)
that might work?

Pat
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (Guest)
on 2008-11-05 00:46
(Received via mailing list)
Sent from my iPhone

On 5. nov.. 2008, at 00.05, Pat Maddox <pergesu@gmail.com> wrote:

>> Thanks
> transactions get rolled back you're back at the db with reference
> data.
> I'm not quite sure how to do that though.  Is there a before(:suite)
> that might work?
>

There is no need for a special construct. Just do it at the top level
in env.rb or an adjacent file. Use at_exit for a global "teardown".
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2008-11-05 00:55
(Received via mailing list)
Aslak Hellesøy wrote:
>>> I have an issue in that I have some reference data my migrations run
>>> http://rubyforge.org/mailman/listinfo/rspec-users
> There is no need for a special construct. Just do it at the top level
> in env.rb or an adjacent file. Use at_exit for a global "teardown".

I believe they are talking about rspec examples and not cucumber
features...
-Ben
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-05 01:30
(Received via mailing list)
Ben Mabey <ben@benmabey.com> writes:

>>>>
>>>> rspec-users@rubyforge.org
>>
>> There is no need for a special construct. Just do it at the top
>> level in env.rb or an adjacent file. Use at_exit for a global
>> "teardown".
>
> I believe they are talking about rspec examples and not cucumber features...

aslak's right though in that case too.  In your spec_helper, just loop
over the tables and delete everything, then insert the seed data you
want, and it should be good to go.

Pat
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-05 01:42
(Received via mailing list)
On Tue, Nov 4, 2008 at 4:26 PM, Pat Maddox <pergesu@gmail.com> wrote:

>
> aslak's right though in that case too.  In your spec_helper, just loop
> over the tables and delete everything, then insert the seed data you
> want, and it should be good to go.
>

But then Ashley's comment applies: you've got the same facts in two
places.
Best thing is to avoid the dependency, if at all possible.

///ark
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-05 02:00
(Received via mailing list)
"Mark Wilden" <mark@mwilden.com> writes:

> On Tue, Nov 4, 2008 at 4:26 PM, Pat Maddox <pergesu@gmail.com> wrote:
>
>     aslak's right though in that case too.  In your spec_helper, just loop
>     over the tables and delete everything, then insert the seed data you
>     want, and it should be good to go.
>
> But then Ashley's comment applies: you've got the same facts in two places. Best thing 
is to
> avoid the dependency, if at all possible.

Sure, but you can encapsulate all that stuff too.  When I've done stuff
like this in the past (and on second thought I have done it just as
aslak suggested, I just didn't think of it :) we've created some seed
data builders.  Then it becomes a simple matter of SeedData.build_data
to kick off the whole deal.

Pat
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-05 02:18
(Received via mailing list)
On Tue, Nov 4, 2008 at 4:56 PM, Pat Maddox <pergesu@gmail.com> wrote:


> Then it becomes a simple matter of SeedData.build_data
> to kick off the whole deal.
>

That makes sense.

///ark
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-05 04:32
(Received via mailing list)
so is the concept to build up all seed data creation in one
place/method, & then for the rake spec case run this in via the "test"
environment.rb file?

But then if you were to use rake:migrate to drop back a couple of
version you might be in a spot of bother? (ie newest seed data not
then tied to migration)?
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-05 20:20
(Received via mailing list)
"Greg Hauptmann" <greg.hauptmann.ruby@gmail.com> writes:

> so is the concept to build up all seed data creation in one
> place/method, & then for the rake spec case run this in via the "test"
> environment.rb file?

That sounds good.  I typically put it in spec_helper.rb so all
test-related stuff is in one place, but I think it makes a lot of sense
to treat this as part of the environment.


> But then if you were to use rake:migrate to drop back a couple of
> version you might be in a spot of bother? (ie newest seed data not
> then tied to migration)?

Let me know if I'm understanding your problem correctly...if you put the
seed data in test.rb, then it'll try to load it regardless of whether it
matches the db schema.  Is that right?  If that's the case, I suppose
you could do a check to see if you even need to load seed data.
Basically, if there are already users in the test db, no need to do
anything.  This would let you have a fully-migrated db with seed data
that you then migrated down.  But honestly I'm not sure why you would
want to drop the schema back down a couple of versions in the first
place?

Pat
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2008-11-05 20:32
(Received via mailing list)
I'll just point out one more disadvantage of assuming the contents of
the
test database are correct (without 'rake db:test:prepare'). If you
interrupt
a test with Ctrl-C (especially when running autospec), it's possible for
the
transaction not to get rolled back. An uncommitted transaction should
get
rolled back automatically, but I've seen that fail to happen, at least
with
PostgreSQL 8.1. A test would assume that a given table is empty, they'd
add
a row, expect the count to be 1, and it would fail because of existing
cruft. I eventually learned to run 'rake spec' when weird failures
happened.
Just something to keep in mind.

///ark
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-05 20:47
(Received via mailing list)
"Mark Wilden" <mark@mwilden.com> writes:

> I'll just point out one more disadvantage of assuming the contents of the test database 
are
> correct (without 'rake db:test:prepare'). If you interrupt a test with Ctrl-C 
(especially when
> running autospec), it's possible for the transaction not to get rolled back. An 
uncommitted
> transaction should get rolled back automatically, but I've seen that fail to happen, at 
least
> with PostgreSQL 8.1. A test would assume that a given table is empty, they'd add a row, 
expect
> the count to be 1, and it would fail because of existing cruft. I eventually learned to 
run
> 'rake spec' when weird failures happened. Just something to keep in mind.

Well that is fascinating.  It seems very, very wrong.  Something I might
expect from MySQL, but never postgres... :)

Pat
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2008-11-06 08:33
(Received via mailing list)
how to I get a model statement to run within "test.rb" by the way?
For example to get the following to run:

      RecurringType.create(:name => "TYPE_BASIC")

If I just stick this in I get:

--------------------extract------------------
Macintosh-2:myequity greg$ rake spec
(in /Users/greg/source/myequity)
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/connection_adapters/abstract/connection_specification.rb:265:in
`retrieve_connection': ActiveRecord::ConnectionNotEstablished
(ActiveRecord::ConnectionNotEstablished)
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in
`connection'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/base.rb:1149:in
`columns'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/base.rb:2616:in
`attributes_from_column_definition_without_lock'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/locking/optimistic.rb:55:in
`attributes_from_column_definition'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/base.rb:2137:in
`initialize'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/base.rb:642:in
`new'
        from
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/base.rb:642:in
`create'
        from
/Users/greg/source/myequity/config/environments/test.rb:24:in
`load_environment'
         ... 14 levels...
        from
/Users/greg/source/myequity/vendor/plugins/rspec/lib/spec/runner/example_group_runner.rb:13:in
`load_files'
        from
/Users/greg/source/myequity/vendor/plugins/rspec/lib/spec/runner/options.rb:98:in
`run_examples'
        from
/Users/greg/source/myequity/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in
`run'
        from /Users/greg/source/myequity/vendor/plugins/rspec/bin/spec:4
rake aborted!
Command /opt/local/bin/ruby
-I"/Users/greg/source/myequity/vendor/plugins/rspec/lib"
"/Users/greg/source/myequity/vendor/plugins/rspec/bin/spec"
"spec/lib/hash_extensions_spec.rb" "spec/models/bank_account_spec.rb"
"spec/models/frequency_spec.rb" "spec/models/interest_rate_spec.rb"
"spec/models/projections/projections_spec.rb"
"spec/models/recurring_spec.rb" "spec/models/recurring_type_spec.rb"
"spec/models/transaction_spec.rb" --options
"/Users/greg/source/myequity/spec/spec.opts" failed
--------------------------
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2008-11-06 17:41
(Received via mailing list)
Oh, I guess it makes sense that it wouldn't work there.  The stuff in
test.rb is run as part of the initializer block, meaning that Rails
hasn't been set up yet there.  I would just stick it all in
spec_helper.rb.  That's what I do and was my initial instinct, because
it keeps all the test setup in one place.  And it looks like it's by far
the easiest way, too :)

Pat



"Greg Hauptmann" <greg.hauptmann.ruby@gmail.com> writes:
This topic is locked and can not be replied to.