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.