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 2007-10-23 11:42
on 2007-10-23 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 2007-10-23 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 2007-10-23 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 2007-10-23 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 2007-10-23 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 2007-10-23 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 2007-10-23 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 2007-10-24 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 2007-10-25 07:06
A patchified version of Rathole is available for your amusement: http://dev.rubyonrails.org/ticket/9981 ~ j.
on 2007-10-25 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.
Enable email notification
Enable multi-page view