Forum: Ruby on Rails Is unit testing really that necessary?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2c2f3ce7125411ff78a1d3e902aa2a4d?d=identicon&s=25 Bob Sanders (adistarmid)
on 2009-04-18 18:47
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?
Bce1d1b7c3ec7b577dcb42e254899e6b?d=identicon&s=25 Michael Schuerig (Guest)
on 2009-04-18 20:38
(Received via mailing list)
On Saturday 18 April 2009, Bob Sanders 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 Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-04-18 21:18
(Received via mailing list)
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.
059ed46172a087063ce26250e44c8627?d=identicon&s=25 Fernando Perez (fernando)
on 2009-04-18 21:54
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?
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.
5772c599ccab3081e0fffb1d54f3b6de?d=identicon&s=25 Andrew Timberlake (andrewtimberlake)
on 2009-04-19 05:19
(Received via mailing list)
On Sat, Apr 18, 2009 at 6:47 PM, Bob Sanders
<rails-mailing-list@andreas-s.net> 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 Timberlake
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake

"I have never let my schooling interfere with my education" - Mark Twain
44a43e7fef8e933e802a7802b4bd3525?d=identicon&s=25 John Small (johnsmall)
on 2009-04-19 13:34
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 Small
2dddec0f7717cae77ac6bceede6be5bc?d=identicon&s=25 Ram (Guest)
on 2009-04-20 07:05
(Received via mailing list)
Incidentally we had quite a discussion on this here
http://groups.google.com/group/rubyonrails-talk/br...
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 Small <rails-mailing-l...@andreas-s.net>
This topic is locked and can not be replied to.