dynamic specs

View: New views
4 Messages — Rating Filter:   Alert me  

dynamic specs

by David Green :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'd like to test that my model attributes are properly protected against mass assignment, something like:

it "should NOT update :balance on mass assignment" do
  @account.attributes = {:balance => 1000}
  @account.balance.should_not == 1000
end

instead of doing each attribute manually however, I'd like to automate it so I can pass a list of attributes which CAN be assigned that way and let the code figure out what should be protected. Here's what I have so far :

http://pastie.caboo.se/70685

the problem is, I can't figure out how to make "protected attributes" reusable. I'd like to be able to pass it a different class name and list of allowed attributes at run time, but AFAIK, shared behaviours can't be sent parameters. I tried using instance variables, which I initialize in 'mass assignments' before() method, but they're only available to the actual spec (lines 6-8), not the code that generates the dynamic specs (lines 3-9)

can anyone think how I might get round this?

thanks
dave


Re: dynamic specs

by David Chelimsky-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 6/15/07, David Green <justnothing@...> wrote:

>
> I'd like to test that my model attributes are properly protected against mass
> assignment, something like:
>
> it "should NOT update :balance on mass assignment" do
>   @account.attributes = {:balance => 1000}
>   @account.balance.should_not == 1000
> end
>
> instead of doing each attribute manually however, I'd like to automate it so
> I can pass a list of attributes which CAN be assigned that way and let the
> code figure out what should be protected. Here's what I have so far :
>
> http://pastie.caboo.se/70685
>
> the problem is, I can't figure out how to make "protected attributes"
> reusable. I'd like to be able to pass it a different class name and list of
> allowed attributes at run time, but AFAIK, shared behaviours can't be sent
> parameters. I tried using instance variables, which I initialize in 'mass
> assignments' before() method, but they're only available to the actual spec
> (lines 6-8), not the code that generates the dynamic specs (lines 3-9)
>
> can anyone think how I might get round this?

I can't think of a good way to do it with the existing tool-set,
however it does bring up an interesting idea. Check this out and let
me know what you think:

http://pastie.caboo.se/70700

It's not currently supported, but it solves the problem of
parameterizing shared behaviours a bit more explicitly than the
current magic of setting instance variables in before(:each).

WDYT?

>
> thanks
> dave
>
>
> --
> View this message in context: http://www.nabble.com/dynamic-specs-tf3927280.html#a11137640
> Sent from the rspec-users mailing list archive at Nabble.com.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

Re: dynamic specs

by David Chelimsky-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 6/15/07, David Chelimsky <dchelimsky@...> wrote:

> On 6/15/07, David Green <justnothing@...> wrote:
> >
> > I'd like to test that my model attributes are properly protected against mass
> > assignment, something like:
> >
> > it "should NOT update :balance on mass assignment" do
> >   @account.attributes = {:balance => 1000}
> >   @account.balance.should_not == 1000
> > end
> >
> > instead of doing each attribute manually however, I'd like to automate it so
> > I can pass a list of attributes which CAN be assigned that way and let the
> > code figure out what should be protected. Here's what I have so far :
> >
> > http://pastie.caboo.se/70685
> >
> > the problem is, I can't figure out how to make "protected attributes"
> > reusable. I'd like to be able to pass it a different class name and list of
> > allowed attributes at run time, but AFAIK, shared behaviours can't be sent
> > parameters. I tried using instance variables, which I initialize in 'mass
> > assignments' before() method, but they're only available to the actual spec
> > (lines 6-8), not the code that generates the dynamic specs (lines 3-9)
> >
> > can anyone think how I might get round this?
>
> I can't think of a good way to do it with the existing tool-set,
> however it does bring up an interesting idea. Check this out and let
> me know what you think:
>
> http://pastie.caboo.se/70700
>
> It's not currently supported, but it solves the problem of
> parameterizing shared behaviours a bit more explicitly than the
> current magic of setting instance variables in before(:each).

Actually, looking at implementing this, it would require a complete
redesign of shared behaviours, and I don't see that happening any time
soon.

>
> WDYT?
>
> >
> > thanks
> > dave
> >
> >
> > --
> > View this message in context: http://www.nabble.com/dynamic-specs-tf3927280.html#a11137640
> > Sent from the rspec-users mailing list archive at Nabble.com.
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@...
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

Re: dynamic specs

by David Green :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

David Chelimsky-2 wrote:
>
> I can't think of a good way to do it with the existing tool-set,
> however it does bring up an interesting idea. Check this out and let
> me know what you think:
>
> http://pastie.caboo.se/70700
>
> It's not currently supported, but it solves the problem of
> parameterizing shared behaviours a bit more explicitly than the
> current magic of setting instance variables in before(:each).

Actually, looking at implementing this, it would require a complete
redesign of shared behaviours, and I don't see that happening any time
soon.

>
> WDYT?
>
shame. that would have been perfect. I'd have a go at it myself but don't think my programming quite up to standard (yet). Thanks anyway