Re: [rspec-users] Testing REST webservices? (Not Rails)
On 21 May 2008, at 21:37, Erik Terpstra wrote: I am new to RSpec and BDD. I was wondering if RSpec specifications are a good solution for testing REST webservices (not implemented in Rails). If so, what would be a good way to test something like the API described below? Hi Erik RSpec would be fine to test that, it's just a web app returning XML instead of HTML. You don't say what you are building the web service in. If you want acceptance/integration-style specs that are implementation-independent, you could use the story runner with steps to make HTTP requests. And look at Kyle's rspec_hpricot_matchers for a way of specifying XML output. You will also want unit specs for your models, controllers etc which will be more framework-dependent. That's all I can offer based on your description. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
On 22 May 2008, at 03:49, Andrew Selder wrote: It would be wonderful if there was some option to specify tables that behave like this, that should be loaded at the beginning of the test run, and (optionally) trashed at the end of the run. Or even better, specify that the test script shouldn't touch (build or teardown) these tables at all, and let their migrated state remain. Like Scott said, this shouldn't be a problem. Are you creating your test DB like this? rake db:test:clone If so, try this: rake db:migrate RAILS_ENV=test It will create a test database that is identical to a new production database, instead of an approximation. I have no idea why the Rails team decided would be better to test against an incomplete database, but I always use migrate now, instead of clone. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Story / Redirection to static html within public
With a rails application I'm trying to access the public/ folder from within a rspec story. I have a controller which redirects to: /public/static_html_page.html I have a story written using webat. This story uses the above controller and it expects the redirection. This story always fails as within the story it cannot follow the redirection (Always gives a 500 error). It does not seem to be able to access any public/ content within the story. Within step file of a story this always fails: 'get /index.html' OR visits '/index.html' I looked back at ActionController::IntegrationTest which seems to be where RailsStory gets all its magic from. That lead me to believe that perhaps this was a rails issue? So I'm unsure if: 1. Accessing public/ within a story is just not supposed to be possible. 2. Accessing public/ within ActionController::IntegrationTest is not suppose to be possible. 2. Rspec has a bug 3. Rails has a bug Any ideas? This is down on Rails 2.0.2. Rspec GIT trunk Thanks, -- Joseph Wilk http://www.joesniff.co.uk -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on each
example.
I've inherited a project where a good amount of enumerated data is
stored in the database (US States, statuses, about 15-20 tables
worth. Over all, it's a reasonable decision that leads to solid
production code (acts_as_enumerated is good). This data is read-only
and relatively static; any changes to these tables are done via
migrations.
The problem comes when I'm writing my tests. Obviously all these
tables get wiped with each example.
This should not be the case. Transactions get rolled back, but tables
do not just get wiped clean.
If this static data is being generated in migrations, then you should
be OK. Is it?
Yes, I could specify these as fixtures, but I really don't want to
have to specify 15-20 fixtures on every example. Yes, I could mock/
stub all the values, except that I use many of these values at class
definition time, which means that errors are thrown before I can
even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the
enumeration for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture
file for each of these tables and loading all the fixtures on each
describe block. Not only does this make for ugly code, but I'm sure
it takes a good chunk of time to setup and teardown each of the
tables each example.
It would be wonderful if there was some option to specify tables
that behave like this, that should be loaded at the beginning of the
test run, and (optionally) trashed at the end of the run. Or even
better, specify that the test script shouldn't touch (build or
teardown) these tables at all, and let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there and
it was.
And then when I run rake spec, the test blow up and I looks at the DB
and all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the spec
task calls the spec_prereq task. This task does a db:test:prepare,
which looking at the source for that in the rails gem only copies the
schema from the development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both plugins.
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on
each example.
I've inherited a project where a good amount of enumerated data is
stored in the database (US States, statuses, about 15-20 tables
worth. Over all, it's a reasonable decision that leads to solid
production code (acts_as_enumerated is good). This data is read-
only and relatively static; any changes to these tables are done
via migrations.
The problem comes when I'm writing my tests. Obviously all these
tables get wiped with each example.
This should not be the case. Transactions get rolled back, but
tables do not just get wiped clean.
If this static data is being generated in migrations, then you
should be OK. Is it?
Yes, I could specify these as fixtures, but I really don't want to
have to specify 15-20 fixtures on every example. Yes, I could mock/
stub all the values, except that I use many of these values at
class definition time, which means that errors are thrown before I
can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the
enumeration for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture
file for each of these tables and loading all the fixtures on each
describe block. Not only does this make for ugly code, but I'm sure
it takes a good chunk of time to setup and teardown each of the
tables each example.
It would be wonderful if there was some option to specify tables
that behave like this, that should be loaded at the beginning of
the test run, and (optionally) trashed at the end of the run. Or
even better, specify that the test script shouldn't touch (build or
teardown) these tables at all, and let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
Ashley, I am using rake db:migrate RAILS_ENV=test. The values I'm inserting into the tables using migrations are gone by the time the tests run. Andrew On May 22, 2008, at 7:07 AM, Ashley Moran wrote: On 22 May 2008, at 03:49, Andrew Selder wrote: It would be wonderful if there was some option to specify tables that behave like this, that should be loaded at the beginning of the test run, and (optionally) trashed at the end of the run. Or even better, specify that the test script shouldn't touch (build or teardown) these tables at all, and let their migrated state remain. Like Scott said, this shouldn't be a problem. Are you creating your test DB like this? rake db:test:clone If so, try this: rake db:migrate RAILS_ENV=test It will create a test database that is identical to a new production database, instead of an approximation. I have no idea why the Rails team decided would be better to test against an incomplete database, but I always use migrate now, instead of clone. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
Downloaded the latest plugins from Github and got the same results.
The spec rake task still ends up calling db:test:prepare which blows
away the database and reloads only the schema.
Thanks,
Andrew
On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 8:55 AM, Andrew Selder [EMAIL PROTECTED]
wrote:
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there
and it was.
And then when I run rake spec, the test blow up and I looks at the
DB and
all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the
spec task
calls the spec_prereq task. This task does a db:test:prepare, which
looking
at the source for that in the rails gem only copies the schema from
the
development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both
plugins.
AHA!
CURRENT means the latest release, which is 1.1.3, which was released
months ago, before Rails 2.1 RC1.
Try the latest from github:
script/plugin install git://github.com/dchelimsky/rspec.git
script/plugin install git://github.com/dchelimsky/rspec-rails.git
script/generate rspec
See if that makes any difference.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on
each
example.
I've inherited a project where a good amount of enumerated data
is stored
in the database (US States, statuses, about 15-20 tables worth.
Over all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and
relatively static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all these
tables
get wiped with each example.
This should not be the case. Transactions get rolled back, but
tables do
not just get wiped clean.
If this static data is being generated in migrations, then you
should be
OK. Is it?
Yes, I could specify these as fixtures, but I really don't want
to have
to specify 15-20 fixtures on every example. Yes, I could mock/
stub all the
values, except that I use many of these values at class
definition time,
which means that errors are thrown before I can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the
enumeration
for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture
file
for each of these tables and loading all the fixtures on each
describe
block. Not only does this make for ugly code, but I'm sure it
takes a good
chunk of time to setup and teardown each of the tables each
example.
It would be wonderful if there was some option to specify tables
that
behave like this, that should be loaded at the beginning of the
test run,
and (optionally) trashed at the end of the run. Or even better,
specify that
the test script shouldn't touch (build or teardown) these tables
at all, and
let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
Have you tried making it not call db:test:prepare?
On Thu, May 22, 2008 at 7:12 AM, Andrew Selder [EMAIL PROTECTED] wrote:
Downloaded the latest plugins from Github and got the same results.
The spec rake task still ends up calling db:test:prepare which blows away
the database and reloads only the schema.
Thanks,
Andrew
On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 8:55 AM, Andrew Selder [EMAIL PROTECTED] wrote:
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there and it
was.
And then when I run rake spec, the test blow up and I looks at the DB and
all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the spec
task
calls the spec_prereq task. This task does a db:test:prepare, which
looking
at the source for that in the rails gem only copies the schema from the
development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both plugins.
AHA!
CURRENT means the latest release, which is 1.1.3, which was released
months ago, before Rails 2.1 RC1.
Try the latest from github:
script/plugin install git://github.com/dchelimsky/rspec.git
script/plugin install git://github.com/dchelimsky/rspec-rails.git
script/generate rspec
See if that makes any difference.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on each
example.
I've inherited a project where a good amount of enumerated data is
stored
in the database (US States, statuses, about 15-20 tables worth. Over
all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and relatively
static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all these tables
get wiped with each example.
This should not be the case. Transactions get rolled back, but tables do
not just get wiped clean.
If this static data is being generated in migrations, then you should be
OK. Is it?
Yes, I could specify these as fixtures, but I really don't want to have
to specify 15-20 fixtures on every example. Yes, I could mock/stub all
the
values, except that I use many of these values at class definition
time,
which means that errors are thrown before I can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the enumeration
for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture file
for each of these tables and loading all the fixtures on each describe
block. Not only does this make for ugly code, but I'm sure it takes a
good
chunk of time to setup and teardown each of the tables each example.
It would be wonderful if there was some option to specify tables that
behave like this, that should be loaded at the beginning of the test
run,
and (optionally) trashed at the end of the run. Or even better, specify
that
the test script shouldn't touch (build or teardown) these tables at
all, and
let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
On Thu, May 22, 2008 at 9:12 AM, Andrew Selder [EMAIL PROTECTED] wrote:
Downloaded the latest plugins from Github and got the same results.
The spec rake task still ends up calling db:test:prepare which blows away
the database and reloads only the schema.
Well, thanks for trying.
You can't be the first person to run up against this problem. I've run
into it before but not in any rails apps I've worked on.
Sounds like the solution would be something like what Scott and Ashley
are talking about - introducing rake db:migrate or a custom data setup
task after or instead of db:test:prepare.
Thanks,
Andrew
On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 8:55 AM, Andrew Selder [EMAIL PROTECTED] wrote:
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there and it
was.
And then when I run rake spec, the test blow up and I looks at the DB and
all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the spec
task
calls the spec_prereq task. This task does a db:test:prepare, which
looking
at the source for that in the rails gem only copies the schema from the
development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both plugins.
AHA!
CURRENT means the latest release, which is 1.1.3, which was released
months ago, before Rails 2.1 RC1.
Try the latest from github:
script/plugin install git://github.com/dchelimsky/rspec.git
script/plugin install git://github.com/dchelimsky/rspec-rails.git
script/generate rspec
See if that makes any difference.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on each
example.
I've inherited a project where a good amount of enumerated data is
stored
in the database (US States, statuses, about 15-20 tables worth. Over
all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and relatively
static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all these tables
get wiped with each example.
This should not be the case. Transactions get rolled back, but tables do
not just get wiped clean.
If this static data is being generated in migrations, then you should be
OK. Is it?
Yes, I could specify these as fixtures, but I really don't want to have
to specify 15-20 fixtures on every example. Yes, I could mock/stub all
the
values, except that I use many of these values at class definition
time,
which means that errors are thrown before I can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the enumeration
for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture file
for each of these tables and loading all the fixtures on each describe
block. Not only does this make for ugly code, but I'm sure it takes a
good
chunk of time to setup and teardown each of the tables each example.
It would be wonderful if there was some option to specify tables that
behave like this, that should be loaded at the beginning of the test
run,
and (optionally) trashed at the end of the run. Or even better, specify
that
the test script shouldn't touch (build or teardown) these tables at
all, and
let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Story / Redirection to static html within public
On 5/22/08, Joseph Wilk [EMAIL PROTECTED] wrote: With a rails application I'm trying to access the public/ folder from within a rspec story. I have a controller which redirects to: /public/static_html_page.html I assume you mean /static_html_page.html? Your document_root in your webserver should be set to /public thus you should never see /public in your URLs, I have a story written using webat. This story uses the above controller and it expects the redirection. This story always fails as within the story it cannot follow the redirection (Always gives a 500 error). It does not seem to be able to access any public/ content within the story. Rails Integration tests talk directly to controllers, since there is no controller in front of static files there is no way to access them as far as I've seen. Within step file of a story this always fails: 'get /index.html' OR visits '/index.html' I looked back at ActionController::IntegrationTest which seems to be where RailsStory gets all its magic from. That lead me to believe that perhaps this was a rails issue? So I'm unsure if: 1. Accessing public/ within a story is just not supposed to be possible. Correct 2. Accessing public/ within ActionController::IntegrationTest is not suppose to be possible. Correct. 2. Rspec has a bug 3. Rails has a bug Any ideas? We can look at getting webrat to recognize the redirect to file outside the scope of the rails environment. Patches always welcome of course. - Josh -- Josh Knowles phone: 509-979-1593 email: [EMAIL PROTECTED] web:http://joshknowles.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
On 22 May 2008, at 15:25, David Chelimsky wrote: Sounds like the solution would be something like what Scott and Ashley are talking about - introducing rake db:migrate or a custom data setup task after or instead of db:test:prepare. It just occurred to me that I never ran any rake tasks to run the specs- I always used autotest. If the rake task behaviour is a bug then running autotest won't fix that, but it might get around the issue of your database being cleared out. Andrew - do you use autotest in general? If so do you see the same behaviour with it? Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
I tried modifying rspec.rake to read
spec_prereq = File.exist?(File.join(RAILS_ROOT, 'config',
'database.yml')) ? [:testing, db:test:purge, db:migrate] : :noop
task :noop do
end
task :testing do
RAILS_ENV = ENV['RAILS_ENV'] = 'test'
end
which should do what I want, I think. However the db:migrate task
blows up with a message:
rake aborted!
Mysql::Error: No database selected: SHOW TABLES
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/connection_adapters/abstract_adapter.rb:151:in `log'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/connection_adapters/mysql_adapter.rb:299:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/connection_adapters/mysql_adapter.rb:403:in `tables'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/connection_adapters/abstract/schema_statements.rb:313:in
`initialize_schema_migrations_table'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/migration.rb:388:in `initialize'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/migration.rb:357:in `new'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/migration.rb:357:in `up'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/
active_record/migration.rb:340:in `migrate'
/opt/local/lib/ruby/gems/1.8/gems/rails-2.0.991/lib/tasks/
databases.rake:99
I examined the connection item and it is pointing to the right DB.
It's strange since the db:migrate task work in isolation.
Anyway, for now I'll manually setup my db for test.
Thanks all,
Andrew
On May 22, 2008, at 10:25 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 9:12 AM, Andrew Selder [EMAIL PROTECTED]
wrote:
Downloaded the latest plugins from Github and got the same results.
The spec rake task still ends up calling db:test:prepare which
blows away
the database and reloads only the schema.
Well, thanks for trying.
You can't be the first person to run up against this problem. I've run
into it before but not in any rails apps I've worked on.
Sounds like the solution would be something like what Scott and Ashley
are talking about - introducing rake db:migrate or a custom data setup
task after or instead of db:test:prepare.
Thanks,
Andrew
On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 8:55 AM, Andrew Selder [EMAIL PROTECTED]
wrote:
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there
and it
was.
And then when I run rake spec, the test blow up and I looks at
the DB and
all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the
spec
task
calls the spec_prereq task. This task does a db:test:prepare, which
looking
at the source for that in the rails gem only copies the schema
from the
development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both
plugins.
AHA!
CURRENT means the latest release, which is 1.1.3, which was released
months ago, before Rails 2.1 RC1.
Try the latest from github:
script/plugin install git://github.com/dchelimsky/rspec.git
script/plugin install git://github.com/dchelimsky/rspec-rails.git
script/generate rspec
See if that makes any difference.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared on
each
example.
I've inherited a project where a good amount of enumerated data
is
stored
in the database (US States, statuses, about 15-20 tables worth.
Over
all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and
relatively
static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all
these tables
get wiped with each example.
This should not be the case. Transactions get rolled back, but
tables do
not just get wiped clean.
If this static data is being generated in migrations, then you
should be
OK. Is it?
Yes, I could specify these as fixtures, but I really don't want
to have
to specify 15-20 fixtures on every example. Yes, I could mock/
stub all
the
values, except that I use many of these values at class
definition
time,
which means that errors are thrown before I can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?),
%w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the
enumeration
for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a
fixture file
for each of these
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
On May 22, 2008, at 10:19 AM, Andrew Selder wrote:
YEAH!!! I've got it.
I changed my rspec.rake to:
spec_prereq = File.exist?(File.join(RAILS_ROOT, 'config',
'database.yml')) ? [db:test:purge, :testing, db:migrate] : :noop
task :noop do
end
task :testing = :environment do
RAILS_ENV = ENV['RAILS_ENV'] = 'test'
ActiveRecord::Base.establish_connection(RAILS_ENV.to_sym)
end
task :default = :spec
task :stats = spec:statsetup
desc Run all specs in spec directory (excluding plugin specs)
Spec::Rake::SpecTask.new(:spec = spec_prereq) do |t|
t.spec_opts = ['--options', \#{RAILS_ROOT}/spec/spec.opts\]
t.spec_files = FileList['spec/**/*_spec.rb']
end
Thanks for all the assistance from everyone.
This is great stuff Andrew - do you have a blog? If so, please
consider blogging this.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 10:25 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 9:12 AM, Andrew Selder [EMAIL PROTECTED]
wrote:
Downloaded the latest plugins from Github and got the same results.
The spec rake task still ends up calling db:test:prepare which
blows away
the database and reloads only the schema.
Well, thanks for trying.
You can't be the first person to run up against this problem. I've
run
into it before but not in any rails apps I've worked on.
Sounds like the solution would be something like what Scott and
Ashley
are talking about - introducing rake db:migrate or a custom data
setup
task after or instead of db:test:prepare.
Thanks,
Andrew
On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
On Thu, May 22, 2008 at 8:55 AM, Andrew Selder [EMAIL PROTECTED]
wrote:
David,
The static data generated in the migrations in being wiped away.
I did a
rake db:test:purge
followed by
rake db:migrate RAILS_ENV=test
and then looked in my database to verify that the data was there
and it
was.
And then when I run rake spec, the test blow up and I looks at
the DB and
all the static tables are empty.
Looking at the rspec.rake file in the rspec_on_rails plugin, the
spec
task
calls the spec_prereq task. This task does a db:test:prepare,
which
looking
at the source for that in the rails gem only copies the schema
from the
development db.
I'm using Rails 2.1 RC1, and the tagged CURRENT version of both
plugins.
AHA!
CURRENT means the latest release, which is 1.1.3, which was
released
months ago, before Rails 2.1 RC1.
Try the latest from github:
script/plugin install git://github.com/dchelimsky/rspec.git
script/plugin install git://github.com/dchelimsky/rspec-rails.git
script/generate rspec
See if that makes any difference.
Cheers,
David
Thanks,
Andrew
On May 22, 2008, at 9:32 AM, David Chelimsky wrote:
On May 21, 2008, at 9:49 PM, Andrew Selder wrote:
Is it possible to specify that certain tables not be cleared
on each
example.
I've inherited a project where a good amount of enumerated
data is
stored
in the database (US States, statuses, about 15-20 tables
worth. Over
all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and
relatively
static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all
these tables
get wiped with each example.
This should not be the case. Transactions get rolled back, but
tables do
not just get wiped clean.
If this static data is being generated in migrations, then you
should be
OK. Is it?
Yes, I could specify these as fixtures, but I really don't
want to have
to specify 15-20 fixtures on every example. Yes, I could mock/
stub all
the
values, except that I use many of these values at class
definition
time,
which means that errors are thrown before I can even mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?),
%w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the
enumeration
for clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a
fixture file
for each of these tables and loading all the fixtures on each
describe
block. Not only does this make for ugly code, but I'm sure it
takes a
good
chunk of time to setup and teardown each of the tables each
example.
It would be wonderful if there was some option to specify
tables that
behave like this, that should be loaded at the beginning of
the test
run,
and (optionally) trashed at the end of the run. Or even
better, specify
that
the test script shouldn't touch (build or teardown) these
tables at
all, and
let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
Re: [rspec-users] Specifying certain tables NOT to be cleared each example?
I know the problem has been solved but you can supply global fixtures in
your spec_helper.rb file. This avoids having to repeat them for every
describe block.
Spec::Runner.configure do |config|
config.global_fixtures = :table_a, :table_b
end
Zach
On Wed, May 21, 2008 at 10:49 PM, Andrew Selder [EMAIL PROTECTED] wrote:
Is it possible to specify that certain tables not be cleared on each
example.
I've inherited a project where a good amount of enumerated data is stored
in the database (US States, statuses, about 15-20 tables worth. Over all,
it's a reasonable decision that leads to solid production code
(acts_as_enumerated is good). This data is read-only and relatively static;
any changes to these tables are done via migrations.
The problem comes when I'm writing my tests. Obviously all these tables get
wiped with each example. Yes, I could specify these as fixtures, but I
really don't want to have to specify 15-20 fixtures on every example. Yes, I
could mock/stub all the values, except that I use many of these values at
class definition time, which means that errors are thrown before I can even
mock/stub.
For instance, I have a statement like this.
named_scope :open, :conditions = [lead_status_id IN (?), %w{New
Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
Which loads the named_scope using the string version of the enumeration for
clarity's sake. It works great, except for testing.
Does anybody see anyway around this other than creating a fixture file for
each of these tables and loading all the fixtures on each describe block.
Not only does this make for ugly code, but I'm sure it takes a good chunk of
time to setup and teardown each of the tables each example.
It would be wonderful if there was some option to specify tables that
behave like this, that should be loaded at the beginning of the test run,
and (optionally) trashed at the end of the run. Or even better, specify that
the test script shouldn't touch (build or teardown) these tables at all, and
let their migrated state remain.
Thanks,
Andrew
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
Zach Dennis
http://www.continuousthinking.com
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
