I watched the Railscasts video about Cucumber and BDD testing and he mentions to also do unit testing. I figure if the application functions how I want it by passing the functional tests through Cucumber''s BDD testing method, is it really that necessary to do unit testing as well? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Saturday 18 April 2009, Bob Sanders wrote:> I figure if the application functions how I want it by passing the > functional tests through Cucumber''s BDD testing method, is it really > that necessary to do unit testing as well?How do you get to the point that the application passes the functional tests? How do you find the cause when functional tests break? Unit tests are not the only answer, but a pretty good one. Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Bob Sanders wrote:> I watched the Railscasts video about Cucumber and BDD testing and he > mentions to also do unit testing. > > I figure if the application functions how I want it by passing the > functional tests through Cucumber''s BDD testing method, is it really > that necessary to do unit testing as well?Source code has two aspects. It has features that users can see and touch - indirectly. Users know what a "PurchaseOrder" record is, for example. Call this aspect "customer-facing", and use BDD to define it. It also has aspects that are developer-facing. End users should not know we lock records with something called "optimistic locking" when they edit those records. Use TDD to define these "developer-facing" aspects. I suspect Cucumber can express developer-facing things, but I suspect this would be a waste of time. Developers do not need excessive verbiage that redundantly describes record locking; they just need to write code that locks the freaking record and then assert that it''s locked. Programmers speak the language of source code, and tests cases should try to keep things in one language whenever possible. And you raise an interesting point. I have not yet used Cucumber, but I suspect that some projects out there just maaaaybe are using it to BDD their customer-facing aspects, while neglecting their developer-facing ones. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Bob Sanders wrote:> I watched the Railscasts video about Cucumber and BDD testing and he > mentions to also do unit testing. > > I figure if the application functions how I want it by passing the > functional tests through Cucumber''s BDD testing method, is it really > that necessary to do unit testing as well?Oh, he probably forgot to told you that acceptance testing using Cucumber is super slow, whereas Unit tests can be written blazing fast. You''ll understand what I mean after you write a few acceptance tests. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sat, Apr 18, 2009 at 6:47 PM, Bob Sanders <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I watched the Railscasts video about Cucumber and BDD testing and he > mentions to also do unit testing. > > I figure if the application functions how I want it by passing the > functional tests through Cucumber''s BDD testing method, is it really > that necessary to do unit testing as well?You could test your app using something like Cucumber only and I believe that''s a good start but consider the following: You have an authentication system that protects the administration of some resource. You would have Cucumber scenarios that check your login form, that administrators can see and edit the resource and that non-administrators can''t see the edit buttons or load the edit resource page In order to improve security, you should ensure that people can''t issue the POST and PUT requests directly (which completely by-passes the browser and therefore is not testable by Cucumber (in it''s traditional usage) Enter controller tests that can issue specific calls against the create and update methods covering all sad paths that are achievable directly against the controller ensuring there is no way to change the resource if you are not an admin. It doesn''t stop there, your entire application relies on some methods on your model such as authenticate and admin? etc. Unit tests are your friend here because you can write specific tests to ensure that authenticate works correctly and that no-one can inject their admin status. Andrew Timberlake http://ramblingsonrails.com http://www.linkedin.com/in/andrewtimberlake "I have never let my schooling interfere with my education" - Mark Twain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Cucumber testing is great for the high level stuff, especially when you want to get the non-technical users involved in writing stories about what the application should do. But if you''re doing developer facing testing then development is slower than it needs to be because you have to write translations from pidgin english into test code. Getting that right is a pain, using other peoples canned examples requires using their assumptions about your code and application. Modifying their example translations takes time & so on. If someone else is paying it''s a nice way to do things. You''ve got quasi-natural language scenarios you can sign off, protect your arse and get paid. If you''re writing code for yourself, and paying for your own time, then the extra layer of syntactical sugar just gets in the way. I now use test unit and Shoulda for most stuff, and mix it with WebRat for the integration testing. Writing the tests is faster, I understand the integration scenarios and because they''re close to the actual code they make more sense to me than high level syntactically sugared stuff. I always write masses of unit tests for each model following the TDD philosophy. YMMV John Small -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Incidentally we had quite a discussion on this here http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/716dc8052524f491/2da0b3c68345d314 recently. What you want to do in testing depends largely upon whom you''re writing the tests for and what kind of app you have. DO go through that thread. Its got some very useful points, tips and discussions. Sure put things in perspective for me. On Apr 19, 4:34 pm, John Small <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Cucumber testing is great for the high level stuff, especially when you > want to get the non-technical users involved in writing stories about > what the application should do. But if you''re doing developer facing > testing then development is slower than it needs to be because you have > to write translations from pidgin english into test code. Getting that > right is a pain, using other peoples canned examples requires using > their assumptions about your code and application. Modifying their > example translations takes time & so on. If someone else is paying it''s > a nice way to do things. You''ve got quasi-natural language scenarios you > can sign off, protect your arse and get paid. > > If you''re writing code for yourself, and paying for your own time, then > the extra layer of syntactical sugar just gets in the way. I now use > test unit and Shoulda for most stuff, and mix it with WebRat for the > integration testing. Writing the tests is faster, I understand the > integration scenarios and because they''re close to the actual code they > make more sense to me than high level syntactically sugared stuff. > > I always write masses of unit tests for each model following the TDD > philosophy. > > YMMV > > John Small > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---