Hi all,
Trying to get some opinions about the use of such plugins and in
particular
about how they test, and how we test with them. Can they work well with
BDD
or do they do to much magic and create difficulties for features and
tests
TIA
Hi all,
Trying to get some opinions about the use of such plugins and in
particular
about how they test, and how we test with them. Can they work well with
BDD
or do they do to much magic and create difficulties for features and
tests
TIA
Andrew P. wrote:
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Hey Andrew,
Controllers using such plugins should not pose any difficulty wrapping
features around them at all. How are they any different from any other
controller from the request point-of-view? My current thinking on the
matter is this: Use features, but skip the controller specs. The
features verify the actual behaviour of them alongside the rest of the
stack and provide me with the best confidence that I’m using the plugin
correctly and giving the end-users the functionality that the app needs
to. I don’t see controller specs adding any additional value at this
point. We would simply be testing the plugin’s code over and over
again… There is also no design benefit from mocking/stubbing the
plugins code either.
That is what I have been doing for all the standard RESTful actions. If
I ever need to vary from the basic behaviour that is provided from the
plugins then I then start adding controller specs for that deviating
behaviour. At which point I will stub out what I need to to make the
plugin work.
HTH,
Ben
Ben M. [email protected] writes:
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
My current thinking on the matter is this: Use features, but skip the
controller specs. The features verify the actual behaviour of them
alongside the rest of the stack and provide me with the best confidence
that I’m using the plugin correctly and giving the end-users the
functionality that the app needs to. I don’t see controller specs
adding any additional value at this point. We would simply be testing
the plugin’s code over and over again… There is also no design
benefit from mocking/stubbing the plugins code either.
+2
Pat
On Thu, Dec 11, 2008 at 1:19 PM, Ben M. [email protected] wrote:
matter is this: Use features, but skip the controller specs. The features
verify the actual behaviour of them alongside the rest of the stack and
provide me with the best confidence that I’m using the plugin correctly and
giving the end-users the functionality that the app needs to. I don’t see
controller specs adding any additional value at this point. We would simply
be testing the plugin’s code over and over again… There is also no design
benefit from mocking/stubbing the plugins code either.
That is what I have been doing for all the standard RESTful actions. If I
ever need to vary from the basic behaviour that is provided from the plugins
then I then start adding controller specs for that deviating behaviour. At
which point I will stub out what I need to to make the plugin work.
+1
–
Zach D.
http://www.continuousthinking.com
Andrew P. wrote:
Hi all,
Trying to get some opinions about the use of such plugins and in
particular
about how they test, and how we test with them. Can they work well with
BDD
or do they do to much magic and create difficulties for features and
tests
5 months after the initial post, any experience to share? I am about to
use one of these plugins in order to simplify my admin controllers code.
Thanks for your feedback
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs