All, I've recently extracted a plugin that significantly improves (well, I hope) fixtures. I'd originally written it as a backwards-compatible patch, but I'd like to get some comments on the approach before I shove it into Trac. I tossed it out on #rails-contrib, and bitsweat thought it might benefit from a larger audience. Major benefits include constant generated ID's, specification of belongs_to/has_one associations by label, and the total obliteration of HABTM join table fixtures. Kindly pile on the comments. :) Plugin and a pretty extensive README at http://svn.geeksomnia.com/rathole/trunk. ~ j.
on 23.10.2007 11:42
on 23.10.2007 12:28
On 10/22/07, John Barnette <jbarnette@gmail.com> wrote: > > All, > > I've recently extracted a plugin that significantly improves (well, I > hope) fixtures. I'd originally written it as a backwards-compatible > patch, but I'd like to get some comments on the approach before I > shove it into Trac. "Fixture bashing is a popular hobby, and I'm especially indebted to Courtenay/caboo.se's Awesome Fixtures, which originally talked me down off of the "no more fixtures, ever!" ledge." Aww, shucks..
on 23.10.2007 12:32
On 10/22/07, John Barnette <jbarnette@gmail.com> wrote: > generated ID's, specification of belongs_to/has_one associations by > label, and the total obliteration of HABTM join table fixtures. Kindly > pile on the comments. :) > The syntax is great! But this defaults thing is difficult to remember DEFAULTS: &DEFAULTS created_on: <%= 3.weeks.ago.to_s(:db) %> first: name: Smurf <<: *DEFAULTS
on 23.10.2007 12:40
On 10/22/07, Courtenay <court3nay@gmail.com> wrote: > The syntax is great! But this defaults thing is difficult to remember > > DEFAULTS: &DEFAULTS > created_on: <%= 3.weeks.ago.to_s(:db) %> > > first: > name: Smurf > <<: *DEFAULTS Absolutely, and it would be really easy to support a DEFAULTS key internally instead of letting YAML do it. I originally avoided supporting the defaults internally to keep the code from bloating, but that might be a lame reason. ~ j.
on 23.10.2007 14:40
John, I still think the syntax is a little wet... When you're just specifying lists of things (like, apples, oranges and grapes): apple: name: apple orange: name: orange grape: name: grape It'd be cool if you could collapse all that: fruits: grape, orange, apple (this being fruits.yml) alternatively - in DEFAULTS, you could have keys that have a 'collapse' value.... and that collapses to the block key.... OK, that probably makes no sense at all, but if it does, it'd be awesome if it had that support... - james On 23 Oct 2007, at 06:49, John Barnette wrote: >> <<: *DEFAULTS > > Absolutely, and it would be really easy to support a DEFAULTS key > internally instead of letting YAML do it. I originally avoided > supporting the defaults internally to keep the code from bloating, but > that might be a lame reason. > > > ~ j. > > > -- James Cox, Internet Consultant t: 07968 349990 e: james@imaj.es w: http://imaj.es/
on 23.10.2007 15:03
On 10/23/07, James Cox <james@imajes.info> wrote: > > grape: > name: grape > > It'd be cool if you could collapse all that: > > fruits: grape, orange, apple > erm, IMO this is a case for some programattic record creation in your actual test helper. %w( apple orange banana ).each { |fruit| Fruit.create(:name => fruit) } my fixtures tend to be named after their function, so invalid_name: name: Joe'"; DROP TABLE users id: 4 address: 1 Main St, .. email: joe@foo.bar missing_email: name: Joe id: 5 etc. Courtenay
on 23.10.2007 15:20
On 23 Oct 2007, at 09:49, Courtenay wrote: >> It'd be cool if you could collapse all that: > > id: 5 > fixtures which are named after their function aren't a bad idea, however, I tend to do this within my tests: it "Should have a valid name" do Fruit.create(valid_fruit_fixture.without(:name)) end So having fewer valid fixtures, and remove/add values as i need them to test. so having some kind of shortcut for name and the name of the fixture mightn't be horrible. - james
on 23.10.2007 18:49
On 10/23/07, James Cox <james@imajes.info> wrote: > I still think the syntax is a little wet... When you're just specifying > lists of things (like, apples, oranges and grapes): I see what you're going for, but I actually haven't run in to the need for something like that: If it's a simple list that you're rarely going to be adding properties to, why not write it out in expanded form the one time and be done? OTOH, if you find yourself adding *any* properties to the list entries, you're going to want them in expanded form anyways. I'm trying to keep Rathole's changes as minimal as possible: I think keeping things very focused will increase the chances of getting this (or something like it) folded back into Rails proper. It should be pretty darn easy for you to write a plugin that provides the features you're looking for, though. :) ~ j.
on 24.10.2007 20:23
On 23-okt-2007, at 7:45, Courtenay wrote: > The syntax is great! But this defaults thing is difficult to remember > > DEFAULTS: &DEFAULTS > created_on: <%= 3.weeks.ago.to_s(:db) %> /me smells structs & macros, but maybe that's that odd YAML smell getting over ;-) -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl
on 25.10.2007 07:06
A patchified version of Rathole is available for your amusement: http://dev.rubyonrails.org/ticket/9981 ~ j.
on 25.10.2007 07:08
On 10/24/07, Julian Tarkhanov <listbox@julik.nl> wrote: > > DEFAULTS: &DEFAULTS > > created_on: <%= 3.weeks.ago.to_s(:db) %> > > /me smells structs & macros, but maybe that's that odd YAML smell > getting over ;-) Yeow! Serves me right for using the YAML anchor/merge syntax in those examples. :) ~j.
on 26.10.2007 06:37
http://dev.rubyonrails.org/ticket/9981 has been updated: * lots of RDoc * PostgreSQL support for disable_referential_integrity Have at. :) ~ j.