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?

On Saturday 18 April 2009, Bob S. 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 S.
mailto:[email protected]
http://www.schuerig.de/michael/

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

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

On Sat, Apr 18, 2009 at 6:47 PM, Bob S.
[email protected] 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 T.
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake

“I have never let my schooling interfere with my education” - Mark Twain

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

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 S. [email protected]