Rails Testing : Not Just For The Paranoid article

Though I'm primarily working on plain old Ruby with a handful of
Camping here and there, I've been writing a couple articles about
Rails that might be interesting to the novice-to-intermediate crowd.

My article "Rails Testing : Not Just For The Paranoid" just came out
today, and in it I show unit, functional, and integration testing by
example. It was tough to work in 'really cool' examples and keep with
a word limit, but I think it might still be helpful.

http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-jus

I'd be happy to hear feedback from beginners about whether anything
confused you in the article, so I can use those pointers for future
articles.

From the advanced folks, I'd like to know if I'm doing anything that

reeks of bad style. I'm mostly a Rails observer, so that's entirely
possible.

Otherwise, I hope you find the article useful.

-greg

Whoops!

http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-just-for-the-paranoid.html

also a tinyurl:

http://tinyurl.com/24a33s

Gregory,
Thank you for the article you posted on testing. I went through this
and your examples this morning and feel you could help people more if
you taught them the 'rational' that would help one find the right
coding/results equation for testing. Your basic point is that one
"should test everything". I find this hard to swallow in a practical
world with only 24 hour days.

I suggest those interested should look at this article as it seems to
tie together more practical examples:
http://manuals.rubyonrails.com/read/chapter/20
David

Most noticeable issue is that you are not mocking out model methods in
functional tests and never mentioned mocks/stubs at all.
By the way, have you tried rspec? Once tried I'm addicted, despite of
lots of black magic, making it hard to trace down problems, if those
occured, it's really really good.
Also, like most of tech writers does, you're writing on testing from
technical standpoint, while some information on theoretical aspects
would make your article much more valuable.

So what’s the point of testing if you’re not going to have 100% code coverage through your tests? How are you going to prove your application works? If one part of the application is not tested, then you can not trust the rest of your application.
Those who say “there’s not enough time to test,” from my experience, haven’t even given it a try, or want to but are still in the “code first, test afterwards” mentality.
You NEED to write your tests first, THEN your code. It’s the only way you can be sure that all of your code is properly tested. And as for time, it’s a very simple change to project management. The typical, non-TDD project timeline goes like this:

— initial design — | ---- Coding ---- | --------------- testing ------------------ |
With TDD, you basically merge coding and testing, and end up with this project timeline pattern:
— initial design — | ---- TDD ------------------ | – testing – |
So yeah, the coding takes a little longer, but the final end-to-end testing is a VASTLY shorter time period, because you can prove the inner workings of your application, and if you write integration tests as well, you can prove interactivity is correct as well. In the end, projects are done faster, more bug-free, and with a better design and cleaner code.
Jason

Most noticeable issue is that you are not mocking out model methods in
functional tests and never mentioned mocks/stubs at all.

Yup, it was in my original outline but got cut due to article length
constraints

By the way, have you tried rspec? Once tried I'm addicted, despite of
lots of black magic, making it hard to trace down problems, if those
occured, it's really really good.

Actually, I'm going to be doing a 3 part series on BDD for O'Reilly
towards the end of the summer. :slight_smile: I've not been using it much in
practice, but we just swapped ruport-util's tests to specs and will be
using it more in work, too. It seems worth investigating for sure.

Also, like most of tech writers does, you're writing on testing from
technical standpoint, while some information on theoretical aspects
would make your article much more valuable.

Yes, that's probably true. I think that I might expand the article
down the line, but I did consciously avoid theory in it, so I'm not
surprised you mentioned that. Next time around, I'll try to at least
cite a few sources for those who want more background.

If you walk into an application mid way, maybe it'll be tough to
immediately layer code in, that's true. Also, when I first started
doing camping, I didn't really have the time to mess around learning
mosquito (it's test framework) in time for my first gig with it.
However, once you get into TDD/BDD, it becomes entirely possible to
write tests for everything, especially if you write them first.

If you treat them as part of the design process, you spend zero time
writing down things on paper and all the time writing the code. It's
true, you need to have a lot of experience to make Test-First and Test-
Everything make sense for your development process. Still, it's one
of the best skills I've picked up, and while I'll be honest and say I
slip from time to time, usually my code with tests is surprisingly
written faster and has less issues than the code where I've left red
zones or not tested at all.

I'm not talking about slim margins, either. I'm estimating from my
past work, that the increase in productivity is anywhere from 50% to
200% better on any given job.

In terms of Ruport, our almost complete coverage for the core library
has been a tremendous safety net. Not everything was written test-
first, but the stuff that is came out better. That's just my
experience. You might try it for a small project that you can take
the time to learn on, and see how it works for you.

-greg