describe “When a new blank product object gets created” do
before(:each) do @product = Product.new
end
it "should not be valid" do
@product.should_not be_valid
@product.errors.on(:title).should_not be_nil
# plenty other errors to display...
end
end
end
And here is the error message when I run this spec:
spec product_spec.rb
F
ActiveRecord::StatementInvalid in ‘Product The Product model When a new
blank product object gets created should not be valid’
PGError: ERROR: relation “products” does not exist
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
d.adsrc, a.attnotnull
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = ‘products’::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
./product_spec.rb:7:in `new’
./product_spec.rb:7:
Finished in 1.025511 seconds
1 example, 1 failure
I don’t understand why RSpec is trying to look for some kind of
relation. In the spec I am simply calling Product.new
On Tue, Nov 4, 2008 at 11:33 AM, Fernando P. [email protected]
wrote:
–
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
I don’t understand why RSpec is trying to look for some kind of
relation. In the spec I am simply calling Product.new
This spec worked perfectly with MySQL.
I am going to go out on a limb and say that I don’t think this is an
RSpec problem. Outside of the spec, if you launch script/console in
both development and test environments, when you do Product.new, do
you have any issues?
On Tue, Nov 4, 2008 at 11:33 AM, Fernando P. [email protected]
wrote:
@product = Product.new
PGError: ERROR: relation “products” does not exist
I don’t understand why RSpec is trying to look for some kind of
relation. In the spec I am simply calling Product.new
PostgreSQL uses the term ‘relation’ for ‘table’ (hence the term
‘relational
database’). Some folks think that a relation is a relationship between
one
table and another, via a shared column value, or key. However, a
relation is
actually the relationship between the values of the columns in a the
rows of
a table. A database consists of a set of these relations, each of which
satisfies a given logical statement, or predicate. For example, your
products table is set of related columns and rows such that every row
corresponds to a “product” in your system, whose column values match
attributes of that product.
My first guess as to your problem is that you need to run ‘rake
db:migrate’.
Doh! I forgot to run the migrations in the newly created DB.
Hi Fernando
I used to do this all the time, so I made a db:migrate:all task[1]
that means you don’t have to remember which version which DB is on.
Mine is for Merb, but I can only see a couple of lines that should
need changing for Rails. You might find it useful.
Thanks Ashley. And I am sure I will forget to run migration for the test
environment each time I make changes to it. I will create a dumb script
that looks like:
I think it’s actually simpler to do ‘rake db:test:prepare’ rather
than migrate the test database. Migrations can be a pain when you’ve
only got one database to worry about, much less two. The
db:test:prepare task extracts the schema from the development
database, drops the test database, then builds it again with the
schema script. One reason I like it is that I know for sure that my
tests are starting from a known state - empty. The other is that I
know for sure that the test db matches the dev db.
Except, this doesn’t work if your migrations contain seed data, eg
lookup tables. In which case you have to compensate for this in your
spec setups, which is a risky DRY violation. It’s safer to get your
test db into shape the same way you get your production one.
On Tue, Nov 4, 2008 at 1:10 PM, Fernando P. [email protected]
wrote:
Thanks Ashley. And I am sure I will forget to run migration for the test
environment each time I make changes to it. I will create a dumb script
that looks like:
I think it’s actually simpler to do ‘rake db:test:prepare’ rather than
migrate the test database. Migrations can be a pain when you’ve only got
one
database to worry about, much less two. The db:test:prepare task
extracts
the schema from the development database, drops the test database, then
builds it again with the schema script. One reason I like it is that I
know
for sure that my tests are starting from a known state - empty. The
other is
that I know for sure that the test db matches the dev db.
Except, this doesn’t work if your migrations contain seed data, eg lookup
tables. In which case you have to compensate for this in your spec setups,
which is a risky DRY violation. It’s safer to get your test db into shape
the same way you get your production one.
See my response in the other thread. I can imagine situations in
which
none of the solutions I offered would apply, but if possible I would
prefer
them over depending on the contents of the test database.
We had a similar situation at work, where we thought we needed certain
data
in order to test. We had all kinds of problems keeping test and
development
in sync (both schema and data). A closer look showed that that data was
not
in fact necessary. I’m not saying that applies in all cases, of course.
///ark
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
I can imagine situations in