need advice: rails unit testings and form validation
joshc...@gmail.com
Could I get some advice on two separate things:
1) unit testing in rails... specifically, I'm playing around in
rails w/o a db. I get an error when i run a unit test, as in the ones
rails creates for you when you use script/generate blah blah. It
appears to be trying to connect to a db. database.yml still has
defaults because I'm not using one just yet. advice on tdd with rails
in general would be great.
2) I've got a working contact form on my self-tutorial rails app...
but I'd like to do it with a model but not have it tied to a table.
And use validation. Any advice? simpler cases work too.
Thanks!
/teaching self rails & ruby blah blah blah...
Chad Woolley
>
> Hi,
>
> Could I get some advice on two separate things:
>
> 1) unit testing in rails... specifically, I'm playing around in
> rails w/o a db. I get an error when i run a unit test, as in the ones
> rails creates for you when you use script/generate blah blah. It
> appears to be trying to connect to a db. database.yml still has
> defaults because I'm not using one just yet. advice on tdd with rails
> in general would be great.
The Rails Recipes book by Chad Fowler has a recipe on setting up a
database-less app. There may be better or more recent info, google
it.
As for TDD, it's the same as other languages. If you haven't seen it,
check out RSpec and BDD. Mocha is a popular mock framework.
>
> 2) I've got a working contact form on my self-tutorial rails app...
> but I'd like to do it with a model but not have it tied to a table.
> And use validation. Any advice? simpler cases work too.
See the recipe mentioned above. Validation is set up on the model.
Get the Rails book from Pragmatic Programmers, and google it.
Derek Neighbors
I have been interested in using Mocha with rspec, but can never find
the time to play. Is there any chance you will be in town during one
of the next meeting slots and be willing to present on Mocha and rSpec?
--
Derek
threadhead
1) unit testing in rails... specifically, I'm playing around in
rails w/o a db. I get an error when i run a unit test, as in the ones
rails creates for you when you use script/generate blah blah. It
appears to be trying to connect to a db. database.yml still has
defaults because I'm not using one just yet. advice on tdd with rails
in general would be great.
Josh Knowles
> Could I get some advice on two separate things:
Jay Fields has a blog post on how his team approached the problem of
unit tests connecting to the database (1). In my opinion this is
overkill for 90% of the projects out there. I've worked on lots of
large Rails projects who have managed to keep their test suites < 1
minute while still accessing the database during unit tests.
As far as validations, the current implementation is tied very heavily
to ActiveRecord, which is of course tied to the database. I've seen a
few people attempt to extract this into a PoRo, but its a cludge.
As you've probably gathered by now Rails is a very opinionated
framework. Once of those opinions is that you are using a database,
and that every model is backed by a single table. I don't want to
deter you from moving forward, but In my opinion you are causing
yourself quite a bit of grief by going against these assumptions.
Josh
1. http://blog.jayfields.com/2006/06/ruby-on-rails-unit-tests.html
--
Josh Knowles
phone: 509-979-1593
email: joshk...@gmail.com
web: http://joshknowles.com
Chad Woolley
>
> Chad,
>
> I have been interested in using Mocha with rspec, but can never find
> the time to play. Is there any chance you will be in town during one
> of the next meeting slots and be willing to present on Mocha and rSpec?
>
> --
> Derek
Is the regular meeting schedule posted anywhere? I looked on the
group about page and didn't see it....
Chad Woolley
> For simplicity, why not set it up to use SQLite. You can either have SQLite
> save the database in files or memory. If are on Leopard, you don't have to
> install a thing. That would at least allow you to move forward until you
> decide on a db.
>
Or for that matter, just use mysql. It's not hard to set up at all.
And, it's the standard default, which is IMPORTANT in rails :) You
usually always want to try to go with any existing default in rails.
if you don't, you're likely in for some extra work or pain.
I've actually had more problems with sqlite than mysql across various
platforms, drivers, and package managers. Easy to use, not always
easy to get running right.
Josh Knowles
> Is the regular meeting schedule posted anywhere? I looked on the
> group about page and didn't see it....
Chad Woolley
>
> I have been interested in using Mocha with rspec, but can never find
> the time to play. Is there any chance you will be in town during one
> of the next meeting slots and be willing to present on Mocha and rSpec?
>
> --
> Derek
7 PM is about a half hour after I get off work cali-time. :( I'll
try to work it out some month...
Thanks for the invite!
James Britt
The Phoenix Ruby User Group meets on the 2nd Monday of each month
The Rails group meets on the 3rd Tuesday of each month
James
Chad Woolley
> The Phoenix Ruby User Group meets on the 2nd Monday of each month
>
> The Rails group meets on the 3rd Tuesday of each month
So they both share this list?
joshc...@gmail.com
On Dec 5, 10:39 am, "Chad Woolley" <thewoolley...@gmail.com> wrote:
just learning my way around rails and ruby, with the idea of possibly
putting up a very simple rails site. The only real functionality would
be a contract form.
I'd like to make the contact form model-driven, with validation
specified on the model. It just seems right to have the model know how
to validate itself. Anyway, I'll probably figure that out soon.
Regarding the rails db bias.. i'm not opposed to swimming upstream. If
i get most of what I want and can make the rest work the way I want,
then i'm fine with that.
James Britt
>
> Regarding the rails db bias.. i'm not opposed to swimming upstream. If
> i get most of what I want and can make the rest work the way I want,
> then i'm fine with that.
Have you considered using one of the many other Ruby Web frameworks?
Have you looked at Nitro or Iowa or Merb or Ramaze or Camping?
Each is opinionated in its own way, and perhaps there's one who's
presuppositions better match your own.
James Britt
James Britt
Yes. This is the Phoenix Ruby User Group list (see the footer that gets
attached to each post), and when the Rails group stated it made sense to
just share the list.
> >
>
James
joshc...@gmail.com
On Dec 5, 2:28 pm, James Britt <ja...@neurogami.com> wrote:
> Have you considered using one of the many other Ruby Web frameworks?
>
> Have you looked at Nitro or Iowa or Merb or Ramaze or Camping?
>
I've been playing around with rails and castle monorail at the same
time. monorail is a rails inspired .net mvc framework. it doesn't have
the db bias, but there is an AR implementation in the castle project.
Josh Knowles
> time. monorail is a rails inspired .net mvc framework. it doesn't have
> the db bias, but there is an AR implementation in the castle project.
Not to deter you from Rails, but if you're a .net guy already make
sure you check out
http://weblogs.asp.net/scottgu/archive/2007/11/13/asp-net-mvc-framework-part-1.aspx.
joshc...@gmail.com
On Dec 5, 2:56 pm, "Josh Knowles" <joshknow...@gmail.com> wrote:
>
> > I've been playing around with rails and castle monorail at the same
> > time. monorail is a rails inspired .net mvc framework. it doesn't have
> > the db bias, but there is an AR implementation in the castle project.
>
> Not to deter you from Rails, but if you're a .net guy already make
>
> --
Yeah, I know about ms mvc.. waiting for the pre-rtm releases. will be
comparing it to subsonic and monorail. but my ruby/rails interest is
about expanding my non-ms skills.
Preston Lee
> As far as validations, the current implementation is tied very heavily
> to ActiveRecord, which is of course tied to the database. I've seen a
> few people attempt to extract this into a PoRo, but its a cludge.
I've had a small bit of success using *some* validations outside of
ActiveRecord objects by providing a custom constructor, but the
approach is a hack at best and fails horribly for some validations. I
think there'd be a lot of value in decoupling--since not every form
corresponds 1-to-1 with an AR class--but oh well.
Jay
> In my opinion this is
> overkill for 90% of the projects out there.
needs to be made on a project to project basis. I recently started my
own project and left the unit tests hitting the database unit it
annoyed me enough that I started using arbs (arbs.rubyforge.org).
However, gems such as arbs and UnitRecord (http://unit-test-
ar.rubyforge.org/) make it very easy to change to rails-less or
database-less testing. Obviously, the sooner you make the switch the
easier it is since making the switch once you have several unit tests
that hit the database will require you to move a lot of tests to
functionals.
> As far as validations, the current implementation is tied very heavily
> to ActiveRecord, which is of course tied to the database. I've seen a
> few people attempt to extract this into a PoRo, but its a cludge.
(validatable.rubyforge.org). Validatable is simply a module that can
be mixed into any ruby object and provides validations. Also, it gives
you an easy way to test validations one at a time[1]. The ability to
test individual validations is probably my favorite reason for using
validatable.
[1] http://blog.jayfields.com/2007/11/validatable-166-released.html
Chad Woolley
On some of our projects, we have been leaning toward an approach of
doing almost everything in the model. It works pretty well. It is
tied to the DB, but that's not too bad. Slows your tests down, but
not too much - depends on your tolerance (although instant non-db
tests are nice).
Here's some links to posts from my co-worker Nick who is pushing the
envelope on the skinny-controller fat-model formula:
http://www.pivotalblabs.com/articles/2007/07/16/the-controller-formula
http://www.pivotalblabs.com/articles/2007/07/18/creating-multiple-models-in-one-action
http://www.pivotalblabs.com/articles/2007/08/08/advanced-proxy-usage-part-i
http://www.pivotalblabs.com/articles/2007/07/26/access-control-permissions-in-rails-access-control-permissions-in-rails
http://www.pivotalblabs.com/articles/2007/10/16/cuddly-models
-- Chad
Chad Woolley
>
>
> > In my opinion this is
> > overkill for 90% of the projects out there.
>
> Whether or not to disconnect the database is absolutely a choice that
> needs to be made on a project to project basis. I recently started my
> own project and left the unit tests hitting the database unit it
> annoyed me enough that I started using arbs (arbs.rubyforge.org).
> However, gems such as arbs and UnitRecord (http://unit-test-
> ar.rubyforge.org/) make it very easy to change to rails-less or
> database-less testing. Obviously, the sooner you make the switch the
> easier it is since making the switch once you have several unit tests
> that hit the database will require you to move a lot of tests to
> functionals.
>
> > As far as validations, the current implementation is tied very heavily
> > to ActiveRecord, which is of course tied to the database. I've seen a
> > few people attempt to extract this into a PoRo, but its a cludge.
This is interesting, but it seems like it could mask errors that would
be found if you used real activerecord calls. Is the sole motivation
to make tests faster? I'm all for that, but the more I work with
rails the more I'm accepting the "full stack" approach for all tests.
I love mocks, but getting full stack coverage for free in every test
is nice too, and often less brittle and catches more bugs.
>
> Several people are quite happy with validatable
> (validatable.rubyforge.org). Validatable is simply a module that can
> be mixed into any ruby object and provides validations. Also, it gives
> you an easy way to test validations one at a time[1]. The ability to
> test individual validations is probably my favorite reason for using
> validatable.
>
> [1] http://blog.jayfields.com/2007/11/validatable-166-released.html
What's wrong with activerecord validations? The test speed again?
You can have AR objects that aren't persistent but still give access
to other AR features.
joshc...@gmail.com
On Dec 6, 9:44 am, "Chad Woolley" <thewoolley...@gmail.com> wrote:
> On Dec 6, 2007 7:17 AM, Jay <goo...@jayfields.com> wrote:
>
> > > As far as validations, the current implementation is tied very heavily
> > > to ActiveRecord, which is of course tied to the database. I've seen a
> > > few people attempt to extract this into a PoRo, but its a cludge.
>
> This is interesting, but it seems like it could mask errors that would
> be found if you used real activerecord calls. Is the sole motivation
> to make tests faster? I'm all for that, but the more I work with
> rails the more I'm accepting the "full stack" approach for all tests.
> I love mocks, but getting full stack coverage for free in every test
> is nice too, and often less brittle and catches more bugs.
>
>
> You can have AR objects that aren't persistent but still give access
> to other AR features.
seperation of concerns. in order to do unit tests, i had to write a
class that builds up an instance of the database and populates
necessary data. Testing takes a really long time, and aren't really
unit tests. It's functional or integration testing. testing and
debugging this thing is a pain.
the idea of a unit test is to test a single unit of work. testing data
access in a unit test on some business logic doesn't make sense to me,
unless the only point of the unit test is to test data access.
IMO, full stack coverage makes more sense as a function or integration
test.
Chad Woolley
> the idea of a unit test is to test a single unit of work. testing data
> access in a unit test on some business logic doesn't make sense to me,
> unless the only point of the unit test is to test data access.
> IMO, full stack coverage makes more sense as a function or integration
> test.
Yes, unit tests are poorly named in rails. They are really
integration tests of models.