Bob S. 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
indirectly. Users know what a “PurchaseOrder” record is, for example.
this aspect “customer-facing”, and use BDD to define it.
It also has aspects that are developer-facing. End users should not know
lock records with something called “optimistic locking” when they edit
records. Use TDD to define these “developer-facing” aspects.
I suspect Cucumber can express developer-facing things, but I suspect
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
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
customer-facing aspects, while neglecting their developer-facing ones.