CODEWITHSUNDEEP
ruby-on-railsrubyrspectransactionsrails-activerecord
tdgs
tdgs

Reputation: 1096

How to test that a certain function uses a transaction in Rails and rspec 2

I have a model function that I want to make sure uses a transaction. For example:

class Model 
  def method
    Model.transaction do
      # do stuff
    end
  end
end

My current approach is to stub a method call inside the block to raise an ActiveRecord::Rollback exception, and then check to see if the database has actually changed. But this implies that if for some reason the implementation inside the block changed, then the test would break.

How would you test this?

Upvotes: 37

Views: 19143

Answers (7)

Kris
Kris

Reputation: 19948

Given a method as such:

class ApplicationJob < ActiveJob::Base 
  private

  def transaction(&block)
    # yield
    ActiveRecord::Base.transaction(&block)
  end
end

In the spec call the private method passing a block which changes the database and then raises:

RSpec.describe ApplicationJob do
  describe 'helper methods' do
    subject(:job) { Class.new(described_class).new }

    describe '#transaction' do
      it 'runs block in transaction' do
        block = lambda { FactoryBot.create(:user); raise; }
        expect { job.send(:transaction, &block) rescue nil }.not_to change(User, :count)
      end
    end
  end
end

If you change the transaction method to just yield you will see the database is changed even after raising.

Upvotes: 0

emrass
emrass

Reputation: 6444

You should look at the problem from a different perspective. Testing whether a function uses a transaction is useless from a behavioral viewpoint. It does not give you any information on whether the function BEHAVES as expected.

What you should test is the behavior, i.e. expected outcome is correct. For clarity, lets say you execute operation A and operation B within the function (executed within one transaction). Operation A credits a user 100 USD in your app. Operation B debits the users credit card with 100 USD.

You should now provide invalid input information for the test, so that debiting the users credit card fails. Wrap the whole function call in an expect { ... }.not_to change(User, :balance).

This way, you test the expected BEHAVIOR - if credit card debit fails, do not credit the user with the amount. Also, if you just refactor your code (e.g. you stop using transactions and rollback things manually), then the result of your test case should not be affected.

That being said, you should still test both operations in isolation as @luacassus mentioned. Also, it is exactly right that your test case should fail in case you made an "incompatible" change (i.e. you change the behavior) to the sourcecode as @rb512 mentioned.

Upvotes: 42

konyak
konyak

Reputation: 11716

A big gotcha needs to be mentioned: When testing transaction, you need to turn off transactional_fixtures. This is because the test framework (e.g Rspec) wraps the test case in transaction block. The after_commit is never called because nothing is really committed. Expecting rollback inside transaction doesn't work either even if you use :requires_new => true. Instead, transaction gets rolled back after the test runs. Ref http://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html nested transactions.

Upvotes: 23

vishB
vishB

Reputation: 1688

Try Testing In rails console Sandbox mode

rails console --sandbox

Upvotes: -6

luacassus
luacassus

Reputation: 6720

Generally you should use "pure" rspec test to test chunks of application (classes and methods) in the isolation. For example if you have the following code:

class Model 
  def method
   Model.transaction do
     first_operation
     second_operation
   end
end

you should test first_operation and second_operation in separate test scenarios, ideally without hitting the database. Later you can write a test for Model#method and mock those two methods.

At the next step you can write a high level integration test with https://www.relishapp.com/rspec/rspec-rails/docs/request-specs/request-spec and check how this code will affect the database in different conditions, for instance when second_method will fail.

In my opinion this is the most pragmatic approach to test a code which produces complex database queries.

Upvotes: 7

Renra
Renra

Reputation: 5649

I've been doing the same but now I think perhaps all you need to do is test that the 'transaction' method has been called on the model in one spec and then test the body of the block in other separate specs. Though that would not ensure that the transaction wraps your method calls as your current test does and not some other code that can be in there.

Upvotes: 1

rb512
rb512

Reputation: 6948

First, you need to enclose your Model.transaction do ... end block with begin rescue end blocks.

The only way to check for transaction rollbacks is to raise an exception. So your current approach is all good. As for your concern, a change in implementation would always mean changing the test cases accordingly. I don't think it would be possible to have a generic unit test case which would require no change even if the method implementation changes.

I hope that helps!

Upvotes: 2

Related Questions