RSpec and DRYness

[Jim Gay-2]

I'm curious about the reaction from Radiant Devs on this
http://www.lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies

It was recently met with some praise on the RSpec list, and appeared  
at a time when I was trying to slog through the Radiant specs.

I'm trying to get more familiar with the Radiant internals so that I  
might be able to contribute more but I find it difficult for two  
reasons. One is that there is plenty of code that is unfamiliar to me  
(which is to be expected), and the other is that the specs are broken  
apart so much.

When I was trying to spec out my changes to if_content, I became  
frustrated that my specs kept failing even though I knew the code was  
correct. I would look at the specs and see the scenarios and then  
start searching them for usable information:
Let's look at the users_scenario. Not there. How about the  
pages_scenario? Ok, it calls the home_page_scenario, let's check  
there. Aha! There's the page with parts I can test.
Then my spec would say:
page.should render('<r:if_content part="body, extended">true</
r:if_content>').as('true')

And it would fail.

I couldn't figure out why until I realized that there was some before  
block setting up yet another page that the other surrounding specs  
were using and it didn't have any of the parts that I thought would be  
there. Ugh.
page(:home).should render('<r:if_content part="body, extended">true</
r:if_content>').as('true')
And it finally passes.

All the while I was thinking "this would make a lot of sense if I was  
already familiar with this code."

So this is partially a complaint and partially a plea for help. I'd  
like to be a more productive supporter of Radiant, but things like  
this eat up time and while it was a valuable lesson in working with  
the specs for Radiant, it also means the next newbie like myself that  
comes along may run into the same problems.

I'm sure someone could argue that I join the documentation wave that's  
going on and write this down somewhere... but I am working on a help  
extension, so its got my back! :-)

-Jim

--~--~---------~--~----~------------~-------~--~----~
Radiant CMS Dev Mailing List
Post:        radiantcms-dev@...
Unsubscribe: radiantcms-dev-unsubscribe@...
Group Site:  http://groups.google.com/group/radiantcms-dev/
-~----------~----~----~----~------~----~------~--~---

I've also found the scenarios hard to navigate.

I'd much prefer a style more like this (http://github.com/tricycle/
radiant-trike-tags-extension/tree/master/spec/models/
trike_tags_spec.rb) - describe blocks with the minimal set of pages
they rely on generated in before blocks nice and close to the code.

(There's lots we could do to clean up the rest of this code, I'm not
putting if forward for anything but the significant comprehensibility
benefits in bringing test dependency code closer to the tests.)

-M@
--~--~---------~--~----~------------~-------~--~----~
Radiant CMS Dev Mailing List
Post:        radiantcms-dev@...
Unsubscribe: radiantcms-dev-unsubscribe@...
Group Site:  http://groups.google.com/group/radiantcms-dev/
-~----------~----~----~----~------~----~------~--~---