Paul: So it looks like the "meat" is that third section that starts with
assert_nothing_raised. Is that right?
CB: Exactly. We want our make our app work so that, if a visitor attempts to delete a category record that has a child record, no exception is raised to crash the app. The first two sections are set up. I get a category record and test to make sure I've gotten the one I wanted. Then I create a recipe child record and test to make sure that it got created. Then comes the meat where I try to delete the record, which we know from running the app will raise the StatementInvalid exception. The
assert_nothing_raised assertion traps the exception so that the test will pass or fail, not crash the test case. Then I test again, just to make doubly sure that the category record is still there. Finally, I delete the recipe record I just created. If I don't delete that record, I'll have trouble on the next test method when Rails tries to load the categories fixture with a record in the recipe table. So, now we're ready to run our category Unit test.
CB: Don't worry. It's not as bad as it looks. In fact, it's pretty much exactly what we wanted. We've got a failing test! Take a closer look, starting at the top. Our
test_cannot_delete_record_with_child ran first and failed right where we wanted it to fail: at
assert_nothing_raised. If you look closely, you'll see that each error after that is associated with a different test method. Rails stops the execution of a test method as soon as it encounters either a failure or an error. When we got the failure we were looking for, Rails stopped the execution of that method. That meant that the child record never got deleted and, as we already knew would happen, the categories fixtures can't load. That's what all the errors are about. So, let's write some code to fix our failure! Let's open our category model.