rspec users - Jul 2008 - Does RSpec work nicely with UUID primary keys?

I have my application happily generating UUID primary keys using the
uuidtools gem.

But the auto-generated specifications created by "script/generate
rspec_scaffold...", etc, assume that one is using a sequential integer
primary key.

For those who have hit this same issue, is it just a matter of rewriting
the auto-generated specifications to take this into account, or does one
have to dig into the code of rspec because this assumptions is hardwired
in?

Thanks in advance.
-- 
Posted via http://www.ruby-forum.com/.

On Jul 5, 2008, at 9:03 AM, John Knox wrote:
> I have my application happily generating UUID primary keys using the
> uuidtools gem.
>
> But the auto-generated specifications created by "script/generate
> rspec_scaffold...", etc, assume that one is using a sequential integer
> primary key.
>
> For those who have hit this same issue, is it just a matter of  
> rewriting
> the auto-generated specifications to take this into account, or does  
> one
> have to dig into the code of rspec because this assumptions is  
> hardwired
> in?
What happens when you run the generated examples?

On Sat, Jul 5, 2008 at 10:03 AM, John Knox <lists at ruby-forum.com>
wrote:
>
> But the auto-generated specifications created by "script/generate
> rspec_scaffold...", etc, assume that one is using a sequential integer
> primary key.
That''s just the fixtures in spec/fixtures.  They''re using the
old
fixture style, where all the IDs are hardcoded.  You can modify the
fixtures easily enough simply by removing the ID field from each of
them; if you''re using Rails 2.0 or higher, read up on the "foxy
fixtures" behavior where it handles ID generation and associations in
a much smarter way.

Better yet, for more flexibility, get rid of the fixtures entirely and
create your test data using some sort of factory method.  If you''re
doing something fundamentally different with your data like UUID
primary keys, you might _have_ to do this.  The Peepcode screencasts
about RSpec show easy examples of how to define create_foo() methods
in your specs.  Or you could use one of the various fixture
replacement plugins/gems:

Fixture Replacement 2:
http://replacefixtures.rubyforge.org/
(This is the one I use.  I love it.)

Factory Girl:
http://giantrobots.thoughtbot.com/2008/6/6/waiting-for-a-factory-girl

can_has_fixtures:
http://github.com/benburkert/can_has_fixtures/tree/master

If you use any of these, you will of course end up having to change
the autogenerated specs in spec/models.  But for models at least, the
RSpec generator puts virtually nothing in, so that only means changing
one or two lines of code each time.  I don''t consider that much of a
burden.

-- 
Have Fun,
Steve Eley
Deep Salt Team

David Chelimsky wrote:
> What happens when you run the generated examples?
My code uses single table inheritance (STI) and a MySQL database, so I 
thought it best to create some new simple projects with a single model.

(1) I created a new project using SQLite with a single model.  All 58 
auto-generated specifications ran successfully.

(2) I created a new single-model project using SQLite but added a UUID 
primary key.  All 58 auto-generated specifications ran successfully.

(3) I created a new project using MySQL with a single model.  Again, all 
58 auto-generated specifications ran successfully.

(4) (2) I created a new single-model project using MySQL but added a 
UUID primary key.  All 58 auto-generated specifications ran 
successfully.

Hmm.  So, it''s not the UUIDs that are causing problems with my 
application... but perhaps single table inheritance.  Will do more tests 
and post again when I''ve better defined the problem.

Sorry for the confusion, Dave, but perhaps this will help somebody else 
searching the list.

And Steve, will look into your suggestions for fixtures.  Thanks very 
much.
-- 
Posted via http://www.ruby-forum.com/.

On 5.7.2008, at 18.37, John Knox wrote:
> David Chelimsky wrote:
>> What happens when you run the generated examples?
>
> My code uses single table inheritance (STI) and a MySQL database, so I
> thought it best to create some new simple projects with a single  
> model.
>
> (1) I created a new project using SQLite with a single model.  All 58
> auto-generated specifications ran successfully.
>
> (2) I created a new single-model project using SQLite but added a UUID
> primary key.  All 58 auto-generated specifications ran successfully.
>
> (3) I created a new project using MySQL with a single model.  Again,  
> all
> 58 auto-generated specifications ran successfully.
>
> (4) (2) I created a new single-model project using MySQL but added a
> UUID primary key.  All 58 auto-generated specifications ran
> successfully.
>
> Hmm.  So, it''s not the UUIDs that are causing problems with my
> application... but perhaps single table inheritance.  Will do more  
> tests
> and post again when I''ve better defined the problem.
The thing is, the scaffolding specs are specs for the behaviour of the  
scaffolded controllers/models/views. If you want to change that  
behaviour, your specs should reflect that assumption. If you add some  
new code (without writing new specs for it), even in the form of using  
plugins,  and your existing specs still run, it doesn''t mean your code
is working correctly because you didn''t write specs for that part of  
the functionality yet. Using UUID probably changes things so little  
that (especially if/when they mock the models) it won''t trip the  
scaffolding specs per se.

//jarkko

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080705/1ef777a7/attachment.bin>

Jarkko Laine wrote:
> If you add some new code (without writing new specs for it),
> even in the form of using plugins,  and your existing specs still run,
> it doesn''t mean your code is working correctly because you
didn''t
> write specs for that part of the functionality yet.
That makes a lot of sense, and a useful gotcha to keep in mind. Since 
I''m just in the very early stages of my project, it makes sense for me 
start-over, get my specs working from the beginning, and ensure that 
they still pass after introducing inheritance through the addition of a 
parent class.

Very impressed with the quality of replies on this list. : )
-- 
Posted via http://www.ruby-forum.com/.