Is unit testing really that necessary?

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?

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

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 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

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.