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.
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
And now rerun the test case...
Paul: OK! I think all that leaves is the
test_destroy method. Let's take another look at that.
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.