Rails控制器测试：隔离还是集成测试？

Question

I'm a bit confused when testing Rails controller, whether to test them in isolation(mocking, less DB hits: faster), or in an integration way(no mocking, a lot of DB hits: slower).

Say we have this example:

class ProductsController

  def create
    product = Product.new(product_params)
    if product.save
      redirect_to root_path
    else
      render :new
    end
  end

  private

  def product_params
    require(:product).permit(:name, :price)
  end

end


RSpec.describe ProductsController do

  describe '#create in isolation' do
    it "pass" do
      params = { name: "name", price: 100}
      mocked_product = double(save: true)
      expect(Product).to receive(:new).with(params).and_return(mocked_product)

      post :create, params: { product: params }

      expect(response).to be_redirect
    end
  end

  describe '#create in integration' do
    it "pass" do
      params = { name: "name", price: 100}

      post :create, params: { product: params }

      expect(response).to be_redirect
    end
  end

end

Testing in isolation doesn't hit the DB which makes it faster, however what if in Product model we added a description field that is required, where we forget to add it to product_params method, which will result in Product record not receiving description, and it won't be valid when saved.

Then the first test will pass with no problems, making a false positive that our controller code is okay, where actually it is not because we have to change product_params method for it to work

The second test will fail because we didn't mock creating the product.

I think this is an open question/topic any way, so I wonder if there is best practices when doing controller tests.

EDIT(generalizing the idea)

I think this can be generalized as it is not limited to controllers but the concept of testing in isolation, the basic idea is the following:

Assume we have a function func(x,y), this function has its own units tests. Then when we have another servive(S) calling func, we will just stub func call as it is tested elsewhere, in order to save time from executing func (especially when it consumes time, like DB hits!)

expect(func).to receive(some_x, some_y).and_return(some_value)

This is the basic idea of testing in isolation.

The problem with this, what if the method signature of func didn't change, however the arguments passed to func from S now will make func throw some exception, due to some implementation changes in func itself, where S is still calling func with the old arguments values, which will result in exception now. And since we mocked calls to func, S test won't catch this error and the code will be deployed successfully.

I believe this is the general pattern

Answer 1

It really depends on what your priorities are, and what sacrifices you're willing to make for fast tests.

Mocked data will definitely mean faster tests as you're removing the database layer. The cost of this is that if there is a bug that only arises when your controller is interacting with your data persistence layer, you won't catch the bug. Fast unit testing vs slow full-stack-many-pieces-working-together-at-the-sam- time testing.

Opinions vary on this. The overall trend in rails testing seems to be moving to integration/feature/system tests and abandoning most controller tests. This is because there is a lot more at play these days with advanced CSS styling and Javascript coming into play. There is no right answer.

Answer 2

I would go with the integration mode.

Mocking is useful only for long-running operations. You don't need to mock everything.

Database objects creation should not take a long time as long as you are using transactional database cleaners.

If your ActiveRecord object is doing some other long operations like calling some other third party service, you can mock this long-running operation.

If you still think the isolation mode is more suitable for your case, you can set only one test case using the real object. And the other test cases can do mocking. In this case, the false positive case you have mentioned will be covered.

Answer 3

A quintessential attribute of unit tests and automated testing in general is to be blazing fast. So, all heavyweight resources should be mocked. This includes databases.

In a well designed system, a database is yet another storage medium that should be easily changed without affecting the majority of the code base, only the connector should change. So, in this light, database is a detail that shouldn't concern the automated tests.

Another reason to abandon databases is that it's a temptation to depend on other information available in the database that should've been abstracted from the test.

In Rails, the compromise was made to run tests in an isolated database, hoping it will be fast enough not to waste a lot of time. Paying that price is reasonable given the flexibility a database would give the developer.

After the burst in adopting unit testing, many practitioners went maniac with mocking and gone to far extents with mocking everything without proper judgment regarding where to direct developers efforts and how much gain from such practice. For many ambitious developers, mocking in itself turned to a technical lust! ie the means became a goal.

Moral of the story is, don't overdo anything without thinking it through and making sure the expected effort will payoff.