#187 Testing Exceptions

thx for the cast!

Thanks for this. We're pushing a site into production soon, and this looks like it will help us cover a part of our tests.

Thanks again!

This is exactly what I was looking for :) great job

Thanks, definitely useful stuff.

What generated that nice list of exceptions? That one in file "untitled 1496" ?

Ahh, to get the trace you would run the rake task with --trace, right?

I haven't tried this though..

Thanks Ryan

Keep up the good work.

suggestion if comment.include?('UGG')
 then move to spam

Ryan, you need to do something about the spam. I think you should disable all links that aren't to pastie, github, or the similar.

Wonder why the captcha does not prevent that spam. I just replaced my old captcha (simple_captcha rails plugin) with the recaptcha used here, in the hope that it will work better...

Thanks for the feedback guys. I'm planning to deal with the spam problem soon. Captcha doesn't stop it because it's actual humans spamming AFAIK.

Thanks Ryan, nice screencast. Please post more TDD/BDD videos, I can't seem to get enough of those :)

Thanks again!

Damn, looks like I'll have to rename my forthcoming "Ugg" Gem then! ;-)

At the very least Ryan please disable comments for the older screencasts. New comments on those seem to be about 99% spam.

Thanks as always for your amazing screen-casts. Is the full stack-trace not available in the testing log file? That is where I usually look for errors during testing...

Cheers

Excellent screencast, although nothing of this is new to me :)

One thing I was wondering is why you made integration tests; they seem to be functional tests to me. And, as Matthew Savage said, I think you can get the full trace by running 'rake test:integration --trace'.

I wanted to note that in the iTunes podcast feed, both this episode and the previous one (#187, #186) generate errors when trying to sync with my iPhone. No other Railscast on that feed does. It's the standard "wrong format" message.

Thanks for all your screencasts, greet work.
If you want to access the exception inside your test you can write:

@response.template.instance_variable_get(:@exception)
(Look at the source code for "assert_response" inside ActionPack.)

Since the assertion accept a message as second parameter you can pass the backtrace there:

assert_response :success,
  @response.template.
  instance_variable_get(:@exception).
  backtrace.join("\n")

or put it in a method to cleanup the backtrace, ecc.

Thanks again.

Giacomo

Correcting myself (comment #37):
when no exception is raised (hopefully most of the time) the code calls #backtrace on a nil object. Here a corrected version:

http://pastie.org/693810

Giacomo

How about making it so after x number of people report a comment as spam, it automatically gets hidden. Then you can permanently delete it later if you wish or unhide it if it really isn't spam.

Thanks for the great screencast again!

About the annoying Spam-Problem:

Please try using Akismet.
http://akismet.com/
It works great on thousands of WordPress sites. Without any annoying captcha.

http://github.com/jfrench/rakismet might be a place to start (not used yet).

Regards

I have a solution for the spam. Since most of us know at least a bit about rails (otherwise we wouldn't give a rat's ... about the Railscasts), as a simple question in addition to Captcha for example:

Fill in the blank:

validates_xxxxx_of :firstname, :lastname

or something more funny (and political LOL):

validates_xxxxx_xxx :smartpresidents, :in => "George W. Bush"

Another excellent screencast. Thanks, Ryan.

Tarantula can help here as well.

http://github.com/relevance/tarantula

As you know, many errors like this can be caught just by clicking through the site and inputting both valid and invalid data on every form. But none of us want to do that manually, since it's both a bore and a huge chore. However, Tarantula will happily do the job for you. "Tarantula is a big fuzzy spider. It crawls your Rails application, fuzzing data to see what breaks."

Tarantula will crawl your entire app, and report any 500s or 404s it encounters. It only takes a few minutes to add it to your Rails app. And if you're not already using it, I'll bet it will find at least one issue you didn't know about. And then you can fix it *before* it affects one of your users!

Using Tarantula is not an excuse to avoid writing good integration tests, but it is another valuable tool in your toolbox.

thanks for another great screencast Ryan. Railscasts has become a wonderful reference guide for me. When I'm tackling a given a problem I often remember an episode that covered that topic and I go back and watch the relevant episode again.

It relies heavily on touch because the pages I have a user acting on, are usually a collection of child records. Caching is a big help in this respect.Thanks

Brilliant article! I especially like the work. Thanks dude!

Useful tools! Just info I need. :)

How about New Relic?