Testing in Rails, uniquness of, length_of... Completeness vs. productivity

What is everyone's feelings on this topic...

I am totally onboard with testing, I feel it's critical and the idea
of Test Driven Development is growing on me,especailly after

What I'm wondering is, how deep do you guys go?

For example Rick Olsen tests the validates_presence_of in his tests in
restful_authentication, however he doesn't test the
validates_uniqness_of or the validates_length_of options...

My stance on it is more of an all or nothing, either you test those
lines, or you trust yourself to check them yourself. The more I think
about it, the more I feel tests to check all the validates_xxxxx_xxx
should be done, because you might forget and delete a line, or somone
else might... plus if you were doing TDD, you would say to yourself...
"name has to be unique", write a test to test that... then put the
line it...

However here is where the other side of my brain goes "WAIT A
MINUTE!"... cuz I just wrote maybe 5 or 6 lines of code, to test one
line... doesn't seem very productive.

And my inner battle rages on...

anyone? Buller?

At my company, we probably spend about half our time writing test code.

I'm one of the owners of the business, so the productivity of
test-driven development is not academic to me. I think it's incredibly
productive. Remember, your tests act as:

* a specification
* a debugging framework
* a refactoring safety belt
* a deployment environment check

If I were a customer, I would simply refuse to accept code that I didn't
feel was adequately covered by tests.


Intellectually I can understand that test-first can be more productive, and I've definitely wished I had a set of tests for apps after-the-fact. Yet I still have a hard time getting over the intuitive hurdle when sitting down to do something new that I should write tests first. When I read up on the testing libraries, I'm also a bit daunted by the amount of work it takes to put fixtures & mocks/stubs together.

I also have a hard time thinking of things to test. I've heard you're not supposed to test the framework (b/c it's already got tests) just the stuff you write. But it seems like I'm writing the most trivial bits of the app--the framework is what does the important work. Also, being a database guy, I mostly just think in terms of data integrity when I try to come up w/things to test (e.g., I shouldn't be able to attach a person to a non-existant organization).

End of whine. :wink:

If this is the thing you're stuggling with, I _highly_ recommend trying
BDD using rspec to support user stories.

You can take a _lot_ of stress out of the initial stages of development
by focusing on the definition, specificion and implementation of a few
key user stories.


Hmm--googling "rspec user stories" turns up these links:

(Wonders if this is too old to apply to the current rspec?)


(the free preview for which does not tempt me to purchase, unfortunately).

Are there other links you'd recommend?



Hi SwOrdfish. Good meeting you at RailsConf.

The perceived loss of productivity will easily be recovered as the
application gets larger and exponentially more difficult to debug.
It's an investment in infrastructure. I don't like paying for
insurance, but you gotta have it, and that's what a good test suite
is, insurance. I would sure rather my tests point out some
embarrassing "feature" than my boss or a customer.

Just my "too sense"


I really like that characterization. The most important aspect, to
me, is documentary -- the tests codify your module's 'interface

In the beta version of restful authentication
for example the field length validation *is* tested; the login name
"1234567890_234567890_234567890_234567890" is expected to pass, while
"1234567890_234567890_234567890_234567890_" is expected to fail:
This is not, of course, to test that ActiveRecord's validation. It is
instead to clarify that this design choice was made, and that if the
implementation changes you should carefully consider its interactions
with other modules.

You might also have tests that well outweigh some lines of code if
they express a difficult tradeoff. restful_authentication specs that
"encryption takes longer than #{desired_encryption_expensiveness_ms}ms
to encrypt a password". As computers get faster, or if your security
needs demand a change in one direction or the other, this makes you
stop to weigh 'server load', 'defense against brute force' and
'migration complexity'.

The beta restful_authentication, by the way, also includes a set of
RSpec story tests and helper steps.


Pardee, Roy wrote:

I also have a hard time thinking of things to test...

End of whine. :wink:

At my current job we use pair programming (promiscuous - in 2 hour stints). We just started a new app - Rails 2.0.2, generate a model & controller, and start TDDing.

Four working days and 10 features later, we run rake stats. 80 lines of code, and 250 lines of test. 1:3 ratio, and each feature is getting better than the last.

I'm like... dayam! Someone must be doing _something_ right...

No, you covered the important stuff that's Rails-specific. Of course,
the web is awash with commentary on testing, and as you get into rspec
and or Test::Unit, you'll find some of that commentary useful. :slight_smile:


No, you covered the important stuff that's Rails-specific. Of course, the web is awash with commentary on testing, and as you get into rspec and or Test::Unit, you'll find some of that commentary useful. :slight_smile:

Google assert_latest, assert_xpath, and assert_javascript!