The Plan A

In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways

Wikipedia

Use mocks when you to :

• improve test performances.
• Remove dependencies of external systems.
• control the behavior of a method.

Via MockFight

What to test in a functiona test?

Then what we need to test ?

1. Assert that the page action rendered and returned successful HTTP response code, i.e. 200.
2. Assert that the correct template was rendered.
3. assert that the correct flash message was rendered
4. Assert that action assigns a value to the @user variable.
5. Assert that the right @user object was loaded.

class Admin::UserController
 def test_show
    get :show, :id => 1
    # assert that the http response was 200
    assert_response :success
    # assert that the correct template was rendered
    assert_template 'admin/userr/show'
    # assert that the variable  @user was assigned
    assert assigns( :user)
    # assert that the variable  @user was assigned with the correct values
    assert_equal 'Joel', assigns(:user).first_name
    assert_equal 'Spolsky', assigns(:user).last_name
  end
end

My take on it is that doing BDD is the same as doing TDD well. The problem that I’ve seen with TDD is people tend to think of it as testing, as verification but it’s specification not verification, for several years now. But that’s a hard sell when you’re constantly talking about tests, about assertions, you’re extending something called TestCase, and writing methods that start with “test”. Now, we don’t have to do that anymore in most cases because we just put an annotation on that says “test”. So, it’s hard to get away from that baggage. It’s hard to stop thinking about them as being tests when we are constantly talking about them as tests. And that’s where BDD comes in to make a break from that and start talking in a specification-centric nomenclature, verification-centric vocabulary rather than testing-centric.

Dave Astels.