Hi, I''ve been a .Net developer for a number of years now and I''m a big fan of TDD / BDD. I have been following these principles for a couple of years and use tools such as NUnit for testing purposes. I am now looking at moving across to using RoR for a number of projects and I''m still getting my head around how everything works. I''ve been reading up on RSpec and Cucumber and I have one question looming in my head. (This may be my .Net head messing things up for me). Normally in .Net when TDDing a controller class I would mock out other library classes that the controller calls, such as Repository layer classes. However I notice when using Cucumber people _very_ rarely mock anything and I''m assuming this is because Cucumber is meant for testing the full stack (Integration testing). I''d normally do this with something like Selenium in .Net. My question is, when creating a controller (or other class) that relies on other library classes is it best to just use RSpec rather than Cucumber to mock out the other dependencies and then bring in Cucumber scenarios later when you know your RSpec tests are passing? Thanks John -- Posted via http://www.ruby-forum.com/.
On Thu, Jan 14, 2010 at 5:46 AM, John Polling <lists at ruby-forum.com> wrote:> Hi, > > I''ve been a .Net developer for a number of years now and I''m a big fan > of TDD / BDD. I have been following these principles for a couple of > years and use tools such as NUnit for testing purposes. > > I am now looking at moving across to using RoR for a number of projects > and I''m still getting my head around how everything works. I''ve been > reading up on RSpec and Cucumber and I have one question looming in my > head. (This may be my .Net head messing things up for me). > > Normally in .Net when TDDing a controller class I would mock out other > library classes that the controller calls, such as Repository layer > classes. However I notice when using Cucumber people _very_ rarely mock > anything and I''m assuming this is because Cucumber is meant for testing > the full stack (Integration testing).Cucumber is intended for Acceptance Testing. The entry point into the system can vary. With Rails you can go through the browser (driving Selenium, Watir, etc from Cucumber), start at the router, or even go directly to the model in cases where that''s appropriate. re: Integration testing, everybody has a different definition. Before Rails came along, the prevalent definition that I was aware of was "testing the behaviour of two non-trivial components together." More recently, the definition that makes most sense to me comes from Growing Object Oriented Software [1]. I don''t have the book in front of me, but from memory it is something like "testing your code with other code that you don''t have any control over." Because we need a database for all levels of Rails testing, this suggests that all Rails testing is Integration Testing. In Rails'' terminology, however, "integration testing" means very specifically testing the full stack minus the browser.> I''d normally do this with something like Selenium in .Net. >> My question is, when creating a controller (or other class) that relies > on other library classes is it best to just use RSpec rather than > Cucumber to mock out the other dependencies and then bring in Cucumber > scenarios later when you know your RSpec tests are passing? >"is it best?" is always relative. YMMV. That said, the outside-in process of BDD using Cucumber and RSpec together works well like this (borrowed and modified from the 2nd post in http://groups.google.com/group/cukes/browse_thread/thread/2598d6fcd29bfd86): 1) Identify business need (the very outside) 2) Discuss what feature would solve this need (feature injection) 3) Write a Cucumber scenario that interacts with the system boundaries (that have yet to be written) 4) Run the scenario and watch it fail because the code doesn''t exist yet 5) Write a little piece of the system boundary code that was missing and caused the test to fail 6) Run the scenario and watch it fail again, this time because the code doesn''t do what it needs to yet 7) Write a code example in RSpec 8) Run the code example and watch it fail 9) Write enough code to make it pass 10) Run the scenario and check its status 11) Repeat 7-10 until you have enough code (and not more than just enough) to make the scenario pass. One catch-phrase that comes to mind is "use Cucumber to learn what code to write, use RSpec to write the right code." You should know that there is a trend these days among Cucumber/RSpec/Rails users to _not_ write controller specs on the basis that controllers are covered by the Cucumber scenarios. The benefit is a faster suite that appears to have less duplication between testing layers. The drawback is that you lose the benefit of discovering model interfaces when you''re specifying the controllers in isolation. My view is that this makes sense for the boilerplate stuff, but customizations of the controller are well served with isolated specs in RSpec. More answer than you bargained for, I imagine. HTH, David [1] http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627> > Thanks > > John > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100114/a34f5f93/attachment-0001.html>
Thanks for this David. I suppose the thing I am so used to is testing classes in isolation whereas Cucumber is about testing everything together. Do Rails developers generally not test things in isolation using mocking and stubbing? John -- Posted via http://www.ruby-forum.com/.
On 14 Jan 2010, at 12:33, John Polling wrote:> Do Rails developers generally not test things in isolation using mocking > and stubbing?Yes, that''s what RSpec is for.
On Thu, Jan 14, 2010 at 6:33 AM, John Polling <lists at ruby-forum.com> wrote:> Thanks for this David. > > I suppose the thing I am so used to is testing classes in isolation > whereas Cucumber is about testing everything together. >Did you do all of your testing in NUnit? When I was working on .NET apps, I used FitNesse for acceptance testing and NUnit for isolation testing. With Rails, these same roles are played by Cucumber and RSpec.> Do Rails developers generally not test things in isolation using > mocking and stubbing? >Some do all the time, some never do. I probably do more than most, but I''ve not experienced a lot of the pain that folks who are new to mocks and stubs experience. You''ve got to know when it''s appropriate. HTH, David ps - please be sure to quote the relevant portions of the email you''re responding to so people reading email on their phones don''t have to go digging around for context. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100114/2c3c7a19/attachment.html>
David Chelimsky wrote:> Did you do all of your testing in NUnit? > > When I was working on .NET apps, I used FitNesse for acceptance testing > and > NUnit for isolation testing. With Rails, these same roles are played by > Cucumber and RSpec. >Generally what I do is drive all my individual classes out using NUnit and Rhino.Mocks and then do the acceptance testing later with FitNesse. I think this is the part that I''m confusing myself with as most Cucumber information talks about using scenarios to drive the code out. So Cucumber comes first, whereas I used to do the Acceptance testing after all the other TDD stuff. Maybe that is me doing it wrong though. John -- Posted via http://www.ruby-forum.com/.
John Polling wrote:> Generally what I do is drive all my individual classes out using NUnit > and Rhino.Mocks and then do the acceptance testing later with FitNesse. > > I think this is the part that I''m confusing myself with as most Cucumber > information talks about using scenarios to drive the code out. So > Cucumber comes first, whereas I used to do the Acceptance testing after > all the other TDD stuff. Maybe that is me doing it wrong though. > > John >Hi John. Maybe this will help: http://www.pragprog.com/titles/achbd/the-rspec-book It''s a good book. But when you get to the part about Webrat and Selenium, just know that there are other options if you need them. Peace, Phillip
On Jan 14, 2010, at 8:46 AM, Phillip Koebbe wrote:> John Polling wrote: >> Generally what I do is drive all my individual classes out using >> NUnit >> and Rhino.Mocks and then do the acceptance testing later with >> FitNesse. >> >> I think this is the part that I''m confusing myself with as most >> Cucumber >> information talks about using scenarios to drive the code out. So >> Cucumber comes first, whereas I used to do the Acceptance testing >> after >> all the other TDD stuff. Maybe that is me doing it wrong though. >> >> John >> > > Hi John. Maybe this will help: > > http://www.pragprog.com/titles/achbd/the-rspec-bookD''oh! I should have thought of that! Thanks for the plug :) Cheers, David> It''s a good book. But when you get to the part about Webrat and > Selenium, just know that there are other options if you need them. > > Peace, > Phillip
Phillip Koebbe wrote:> Hi John. Maybe this will help: > > http://www.pragprog.com/titles/achbd/the-rspec-book > > It''s a good book. But when you get to the part about Webrat and > Selenium, just know that there are other options if you need them.Already reading that one thanks :-) It is a good book and it''s helping me get my head around it all. It''s just a case of understanding when to develop using Cucumber and when to user RSpec on it''s own. I think this will come with experience. John -- Posted via http://www.ruby-forum.com/.
hi 2010/1/14 John Polling <lists at ruby-forum.com>> Phillip Koebbe wrote: > > > Hi John. Maybe this will help: > > > > http://www.pragprog.com/titles/achbd/the-rspec-book > > > > It''s a good book. But when you get to the part about Webrat and > > Selenium, just know that there are other options if you need them. > > Already reading that one thanks :-) It is a good book and it''s helping > me get my head around it all. It''s just a case of understanding when to > develop using Cucumber and when to user RSpec on it''s own. I think this > will come with experience. >there''s also this very good presentation by Ben Mabey about when to use which (cucumber or rspec) with the analagy with bikes and bike-gears, only I don''t find the link :-( hth (a bit), joaquin> > John > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- www.least-significant-bit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100114/a72394dd/attachment.html>
On Thu, Jan 14, 2010 at 9:26 AM, Joaquin Rivera Padron <joahking at gmail.com>wrote:> hi > > 2010/1/14 John Polling <lists at ruby-forum.com> > > Phillip Koebbe wrote: >> >> > Hi John. Maybe this will help: >> > >> > http://www.pragprog.com/titles/achbd/the-rspec-book >> > >> > It''s a good book. But when you get to the part about Webrat and >> > Selenium, just know that there are other options if you need them. >> >> Already reading that one thanks :-) It is a good book and it''s helping >> me get my head around it all. It''s just a case of understanding when to >> develop using Cucumber and when to user RSpec on it''s own. I think this >> will come with experience. >> > > there''s also this very good presentation by Ben Mabey about when to use > which (cucumber or rspec) with the analagy with bikes and bike-gears, only I > don''t find the link :-( >http://mwrc2009.confreaks.com/14-mar-2009-15-00-bdd-with-cucumber-ben-mabey.html He leaves out a couple of steps here and there for the sake of time in the presentation, but this gives a great overview. Cheers, David> > hth (a bit), > joaquin > > >> >> John >> >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > www.least-significant-bit.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100114/03b55bef/attachment-0001.html>
John Polling wrote:> Already reading that one thanks :-) It is a good book and it''s helping > me get my head around it all. It''s just a case of understanding when to > develop using Cucumber and when to user RSpec on it''s own. I think this > will come with experience. > > John >Others can explain it better than me (and have), but in a nutshell: - use Cucumber for full stack (as the user would see it) testing. Some call it User Acceptance Testing (UAT) - use RSpec for unit/functional testing (controllers, models, views, helpers) I think of it like this: RSpec is for the developer, Cucumber is for the user. That may be a gross oversimplification, but it works for me. :) But one thing to keep in mind is that you can (and maybe should) use them together. Through Cucumber, you establish the context of what the user will expect. Through RSpec, you establish expectations for the different pieces of the application. That''s why it''s called "Outside In Development": You start with the outside of the black box (what the user interacts with) and then step into the black box (the nuts and bolts that the user doesn''t care about, but you, the developer, do). Yes, it will come with experience. Just be patient, learn from your mistakes, and ask lots of questions! That you have testing knowledge already will help. Once the RSpec/Cucumber light goes on, there will be no stopping you! Peace, Phillip
On Jan 14, 2010, at 12:15 pm, David Chelimsky wrote:> re: Integration testing, everybody has a different definition. Before Rails came along, the prevalent definition that I was aware of was "testing the behaviour of two non-trivial components together." > > More recently, the definition that makes most sense to me comes from Growing Object Oriented Software [1]. I don''t have the book in front of me, but from memory it is something like "testing your code with other code that you don''t have any control over." Because we need a database for all levels of Rails testing, this suggests that all Rails testing is Integration Testing.And yet, JB Rainsberger sticks absolutely uncompromisingly to the first definition[1]. I wonder if you could take it to yet another extreme and include tests for objects with private methods as "integration tests". The thing I got most from GOOS is to protect all domain code with adapters. If all Rails testing is integration testing, that means a lot of duplication and coupling that could be reduced... I have yet to do it for real though. But GOOS is the book that convinced me it''s worth trying. Ashley [1] http://www.infoq.com/presentations/integration-tests-scam -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran
On Jan 14, 2010, at 1:17 pm, John Polling wrote:> I think this is the part that I''m confusing myself with as most Cucumber > information talks about using scenarios to drive the code out. So > Cucumber comes first, whereas I used to do the Acceptance testing after > all the other TDD stuff. Maybe that is me doing it wrong though.The book David mentioned earlier - before the one he wrote himself :) - GOOS[1] has a diagram on p40 that shows how the unit test cycle fits inside the acceptance test cycle. You can extend this to as many layers as you like. I wrote a blog post which has a pretty picture of the idea[2]. Ignore the text, it''s long and rambling and is about something else. I thought it was a great insight, until I realised Kent Beck wrote about self-similarity something like 5+ years ago[3]. Ashley [1] http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 [2] http://blog.patchspace.co.uk/2009/12/customers-input-and-russian-doll-of.html [3] http://www.goodreads.com/book/show/67833.Extreme_Programming_Explained_Embrace_Change -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran
hey there there''s also http://bddcasts.com with railscasts like bdd screencasts haven''t check it much myself, but might deserve a look hth, joaquin 2010/1/14 Ashley Moran <ashley.moran at patchspace.co.uk>> > On Jan 14, 2010, at 1:17 pm, John Polling wrote: > > > I think this is the part that I''m confusing myself with as most Cucumber > > information talks about using scenarios to drive the code out. So > > Cucumber comes first, whereas I used to do the Acceptance testing after > > all the other TDD stuff. Maybe that is me doing it wrong though. > > The book David mentioned earlier - before the one he wrote himself :) - > GOOS[1] has a diagram on p40 that shows how the unit test cycle fits inside > the acceptance test cycle. You can extend this to as many layers as you > like. I wrote a blog post which has a pretty picture of the idea[2]. > Ignore the text, it''s long and rambling and is about something else. I > thought it was a great insight, until I realised Kent Beck wrote about > self-similarity something like 5+ years ago[3]. > > Ashley > > > [1] > http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 > [2] > http://blog.patchspace.co.uk/2009/12/customers-input-and-russian-doll-of.html > [3] > http://www.goodreads.com/book/show/67833.Extreme_Programming_Explained_Embrace_Change > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- www.least-significant-bit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100115/ccb54ef5/attachment.html>
Good explanation Phillip. It gives a clear idea... Thanks Regards, Diwakar Others can explain it better than me (and have), but in a nutshell: - use Cucumber for full stack (as the user would see it) testing. Some call it User Acceptance Testing (UAT) - use RSpec for unit/functional testing (controllers, models, views, helpers) I think of it like this: RSpec is for the developer, Cucumber is for the user. That may be a gross oversimplification, but it works for me. :) But one thing to keep in mind is that you can (and maybe should) use them together. Through Cucumber, you establish the context of what the user will expect. Through RSpec, you establish expectations for the different pieces of the application. That''s why it''s called "Outside In Development": You start with the outside of the black box (what the user interacts with) and then step into the black box (the nuts and bolts that the user doesn''t care about, but you, the developer, do). Yes, it will come with experience. Just be patient, learn from your mistakes, and ask lots of questions! That you have testing knowledge already will help. Once the RSpec/Cucumber light goes on, there will be no stopping you! Peace, Phillip _______________________________________________ rspec-users mailing list rspec-users at rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100115/875a29c0/attachment.html>