Forum: Ruby on Rails RE: The Guilt List

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.
60e38de043848f82392062088f191213?d=identicon&s=25 Hogan, Brian P. (Guest)
on 2006-01-12 21:42
(Received via mailing list)
I just started doing unit tests on my current application because I felt
bad :) I'll figure out functional tests on the next app :)
69b2ef4bce76b5b27c94e898976dc6d8?d=identicon&s=25 matthew clark (Guest)
on 2006-01-12 21:51
(Received via mailing list)
The only guilt I feel in my rails aps is that I now have the time to do
things right, including tests, and can bill for the whole thing.  With
PHP I
used to take short cuts and cheat here and there because that is what
the
clients expected.  They wanted something to work in the shortest amount
of
time possible.

Clients still want that, but with Rails, I can indulge in the guilty
pleasure of testing first, and still get the job done ahead of schedule.

The truth be told, test driven development is actually faster than code
-
reload, so I'm not sure if it is Rails, Tests, or both that have allowed
my
my guilty pleasure.  But I'll give credit to Rails because it makes
testing
so blasted easy.

matt
51f10739fd903d3b57561a15e4598954?d=identicon&s=25 M Daggett (Guest)
on 2006-01-12 21:54
(Received via mailing list)
Actually, this is one of the problems with the concept of 'testing'
which implies that the functionality is completed and therefore just
needs verification that it works as programmed. However, testing for
is not about finding the gaps in my program it is able fleshing out
the requirements of the design in a flexible forgiving structure. Good
testing is about testing assumptions of the domain model as much as it
is about testing the technical implementations. As an example, try
this exercise with a small portion of your application.

Before you dive into the model and the controller and the view, start
writing assumptions you are making about how the application "should"
perform. Lets say we have a User model that needs to manage articles
and images. Before I have written anything in my model I start
brainstorming requirements in my unit tests


test_user_create_image

test_user_destroy_image

test_user_cannot_destroy_others_images

test_user_can_relase_ownership_of_image

test_user_update

test_user_create

etc.etc. etc.

Immediately, I can start to plan out my application, is it smart to
allow the user to create an image from inside the user model? Should
it be abstracted into its own image model instead? These questions are
easy to answer in tests because the code base is at its most flexible
stage. It would be much harder to abstract these relationships when
you have a controller and view tied to the assumptions you made about
your domain..

Anyway that is my two cents.
Mark

On 1/12/06, Hogan, Brian P. <HOGANBP@uwec.edu> wrote:
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
This topic is locked and can not be replied to.