History Tracking With Postgres

Testing Event Tracking

There’s a myth that it’s hard to test your database. In fact it’s quite easy. You can just write regular tests in Ruby. I’m going to use RSpec. The main thing that we want to test is that change tracking happens even when we circumvent ActiveRecord.

⚠ Make sure you’re comfortable writing tests before doing anything fancy with the database.  I don’t normally follow a strict red-green-refactor pattern in my day-to-day work, but I certainly do when building custom logic in the database.

Basic test pattern:

describe Account, type: :model do
  it 'tracks changes in Postgres' do
    valid_parameters = { … }
    model = Account.create!(**valid_parameters)

    # Change one field directly via a SQL statement
    ActiveRecord::Base.connection.execute <<~SQL
      UPDATE "#{model.table_name}"
      SET updated_at = now()
      WHERE id = #{model.id}
    SQL

    # check that 2 archives exist, one for the model creation
    # one for the model that was just updated
    expect(model.archives.count).to eq(2)
    changed_keys = model.most_recent_change.changed_values.keys
    expect(changed_keys).to match_array(["updated_at"])
  end
end

DRY it up with a custom matcher

One of the benefits of this pattern is that you can use it for a lot of tables over and over, so it would be nice if there were a one line custom matcher that would test for our most common use cases.

RSpec.describe Account, type: :model do
  it "should track changes in postgres" do
    valid_params = { … }
    model = Account.create!(**valid_params)
    expect(model).to track_changes_in_postgres
  end
end

require 'rspec/expectations'

RSpec::Matchers.define :track_changes_in_postgres do
  custom_matcher = PostgresChangeTrackingMatcher.new

  match { |model| custom_matcher.matches?(model) }
  failure_message { custom_matcher.failure_message }
  failure_message_when_negated { custom_matcher.failure_message_when_negated }
end

class PostgresChangeTrackingMatcher
  def matches?(model)
    rails_tracking = track_changes_done_in_rails?(model)
    postgres_tracking = track_changes_done_in_postgres?(model)

    if rails_tracking && postgres_tracking
      true
    elsif !rails_tracking && !postgres_tracking
      false
    elsif rails_tracking && !postgres_tracking
      raise RuntimeError.new <<~TXT
        changes were tracked via rails but not via postgres
      TXT
    elsif !rails_tracking && postgres_tracking
      raise RuntimeError.new <<~TXT
        changes were tracked via postgres but not via rails
      TXT
    end
  end

  def track_changes_done_in_rails?(model)
    model.created_at = 2.minutes.ago
    model.updated_at = 1.minute.ago
    model.save!

    most_recent_change = Archive.find_by({
      record_type: model.class.name,
      record_id: model.id,
      most_recent: true
    })

    keys_changed = most_recent_change && most_recent_change.changed_values.keys

    if keys_changed == ['created_at', 'updated_at']
      true
    elsif keys_changed.nil?
      false
    else
      raise RuntimeError.new <<~TXT
        a change was recorded but an unexpected set of fields was changed: #{keys_changed}
      TXT
    end
  end

  def track_changes_done_in_postgres?(model)
    ActiveRecord::Base.connection.execute <<~SQL
      UPDATE "#{model.class.table_name}"
      SET updated_at = now()
      WHERE id = #{model.id}
    SQL

    most_recent_change = Archive.find_by({
      record_type: model.class.name,
      record_id: model.id,
      most_recent: true
    })

    keys_changed = most_recent_change && most_recent_change.changed_values.keys

    if keys_changed == ['updated_at']
      true
    elsif keys_changed.nil?
      false
    else
      raise RuntimeError.new <<~TXT
        a change was recorded but an unexpected set of fields was changed: #{keys_changed}
      TXT
    end
  end

  def failure_message
    "failed to track changes in postgres"
  end

  def failure_message_when_negated
    "model is not supposed to track changes in postgres but it's being tracked anyway"
  end
end

One rule when you define a matcher: you should define expected behavior for both the matcher and its negation. For another model without tracking, we should be able to pass in the following matcher and have it pass.

RSpec.describe SomeOtherModelWithoutTracking, type: :model do
  it "should NOT track changes in postgres" do
    model = FactoryBot.create(:some_other_model_without_tracking)
    expect(model).not_to track_changes_in_postgres
  end
end

When we define the custom matcher, the match block accepts one argument: the object being tested. It either returns true meaning it matches, false meaning it doesn’t match, or it throws an error. This is an important pattern. When we’re testing that a matcher matches, we often want multiple criteria all to come back true. When we’re testing that a matcher does NOT match, we expect multiple criteria all to come back false. If for any reason the criteria are inconsistent, i.e. some come back some true and some false, the test should fail.

I apply the same principle when I’m running smaller sub-tests inside of the matcher. For example, I’m testing whether changes made through ActiveRecord are tracked. That’s either going to return true, return false, or raise an error. The same principle applies when I check that changes made through a raw SQL query are tracked.

Enjoying this content? Consider subscribing to The Gnar’s newsletter.