Cookin' with Ruby on Rails - More Designing for Testability
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Paul: Rendering with nil? What the heck? The controller method says that if the update isn't successful the app's supposed to render the edit template. I don't get it.

CB: Take a step back and think about what we're really testing here. Are we really testing the controller logic you're looking at? We're trying to test the path the app takes if the create is unsuccessful. What caused our create to fail? Our validations! And when a validation fails it generates error messages and displays them to the last page that was rendered. But the internal processes make it happen in a way that makes it a little tough to test for in the most obvious way. Let's fire up the app again and do the same thing our test method here is doing. Click the "Show all categories" link, click on a category name, then click edit. Then delete the name and click the button.

error in the app from trying to update with blank name
Figure 27

CB: See the URL? It still says it's in the update method. I'm guessing that explains the "rendering with <nil>" failure we got since there isn't any "update" template. But it's clear that Rails processed the request and redirected the visitor back to the edit page with error messages. So, let's change the line in your test_update method from

assert_template 'edit'


assert_response :redirect

And now rerun the test case...

testing for a Rails-generated error
Figure 28

Paul: OK! I think all that leaves is the test_destroy method. Let's take another look at that.

another look at the destroy and test_destroy method
Figure 29

Paul: You know, now that I understand the Exception handling assertions a little better, and I remember that we've got good protection both in our code and in our Unit tests to protect against crashes from trying to destroy records that shouldn't be destroyed, I don't think this needs any work. If the assert_nothing_raised fails on the find attempt, the test case will end with failure which will tell us we have a problem with our test data. If the find succeeds, attempting to destroy the record won't cause us a problem. And then we're checking to make sure the record actually was deleted from the table. That's a little redundant with our Unit tests in place, but it's not a problem.

Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Next Pagearrow