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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
