Editing Functional Tests in Rails

There was a time I was afraid of breaking my code. And then there was a time I was less afraid of breaking my code, but I became obsessed with fixing every little error and bug that I ended up wasting time on something relatively trivial when I could be working on more productive matters.

Case in point:

I've been working through the Depot application with Agile Web Development with Rails. This latest chapter had me working through creating a mailer and writing tests for it. Creating the mailer went well, and I can use my own gmail account to send mail through my Depot application! SUCCESS!

However, I got hung up on the functional tests. And I know what the problem is, but not how to fix it.

Here are the errors I get:

1) Error:
test_should_destroy_line_item(LineItemsControllerTest):
ActiveRecord::RecordNotFound: Couldn't find LineItem with ID=980190962 [WHERE ("line_items".cart_id = 980190963)]
app/controllers/line_items_controller.rb:79:in `destroy'
  test/functional/line_items_controller_test.rb:45:in `test_should_destroy_line_item'
  test/functional/line_items_controller_test.rb:44:in `test_should_destroy_line_item'

2) Error:
test_order_shipped(NotifierTest):
ActionView::Template::Error: undefined method `protect_against_forgery?' for #<#:0x1030519d8>
    app/views/line_items/_line_item.html.erb:9:in `_app_views_line_items__line_item_html_erb___1505233713_2172764620_6072364'
    app/views/notifier/order_shipped.html.erb:8:in `_app_views_notifier_order_shipped_html_erb___2127495373_2172826120_0'
    app/mailers/notifier.rb:13:in `order_shipped'
    test/functional/notifier_test.rb:13:in `test_order_shipped'

I have an idea why I'm getting the first error. I've been following the optional exercises at the end of each chapter and I changed the :destroy method in line_items_controller without updating the functional test. Here's the OFFENSIVE code:

def destroy
  @cart = current_cart
  @line_item = @cart.remove_product(@cart.line_items.find(params[:id]))

    respond_to do |format|
      format.html { redirect_to store_url }
      format.js
      format.xml { head :ok }
    end
  end
end

Any idea how to fix this? I'm not super concerned about it, but I'd like to know if I'm on the right track and I think this would be an easy fix. The second error I'm less sure about. I don't get why I'm getting an error for protect_against_forgery? since I'm not calling that method anywhere. Is it a default Rails thing that I'm overlooking?

Anyway, my current strategy has been simply to comment out the tests until later. Which may never come, depending on a variety of factors! I have a sneaking suspicion writing tests will never be one of my strong suits.

Getting back to my original point, it made more sense simply to comment these tests out rather than spend a bunch of time fixing them, especially since my application DOES work. Still, it's a good idea to get a handle on writing tests. I'm doing this for Future Tyler.

Oh I'll test your case, you rogue

I think test cases were designed specifically to give me a headache. This chatbot program I'm developing is going pretty well. I always take it as a good sign that my Ruby studies are progressing when I get a headache afterwards. Or during. Whatever!

Either way, it feels good to be building something that functions. Even though that functionality is limited. Even though the code for that functionality was handed to me. I'm glad the source code was available to download, because after throwing multiple errors I found out I had an extra | in my source code. And I was missing a parenthesis before that. What a slob!

Here's a question: what's the advantage of writing test code rather than simply running the source code and checking for errors that way? My guess is by writing a test code, Ruby is checking that the underlying logic makes sense and works, but if that's the case, wouldn't simply running the source code do the same thing? Is it faster to run tests? More economical for larger programs?

I get the feeling writing test code doesn't make much sense to me now, but it's something more vital for bigger projects where more things can go horribly awry.