# Rails Testing : Not Just For The Paranoid article **URL:** \ **Category:** Rails\ **Created:** [June 7, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268 "2007-06-07T23:03:40Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 7, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/1 "2007-06-07T23:03:40Z")
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. [O'Reilly Media - Technology and Business Training](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 ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 7, 2007, 11:05pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/2 "2007-06-07T23:05:41Z")
On Jun 7, 5:03 pm, Gregory B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. > > [O'Reilly Media - Technology and Business Training](http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-jus)… Whoops! > **[O'Reilly Media - Technology and Business Training](https://www.oreilly.com)** > > Gain technology and business knowledge and hone your skills with learning resources created and curated by O'Reilly's experts: live online training, video, books, our platform has content from 200+ of the world's best publishers. also a tinyurl: > **[O'Reilly Media - Technology and Business Training](https://www.oreilly.com)** > > Gain technology and business knowledge and hone your skills with learning resources created and curated by O'Reilly's experts: live online training, video, books, our platform has content from 200+ of the world's best publishers. ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 8, 2007, 7:47pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/3 "2007-06-08T19:47:54Z")
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](http://manuals.rubyonrails.com/read/chapter/20) David ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 8, 2007, 8:20pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/4 "2007-06-08T20:20:59Z")
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 ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 8, 2007, 8:18pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/5 "2007-06-08T20:18:59Z")
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. ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 8, 2007, 9:01pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/6 "2007-06-08T21:01:04Z")
On Jun 8, 1:46 pm, BraveDave [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. 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 ---
**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\ **Post date:** [June 8, 2007, 8:56pm UTC](https://www.ruby-forum.com/t/rails-testing-not-just-for-the-paranoid-article/106268/7 "2007-06-08T20:56:04Z")
On Jun 8, 2:18 pm, liquidautumn [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. 🙂 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.