Question

Having two classes like this:

class Site < ActiveRecord::Base
  has_one :subscription, dependent: :destroy

  def self.hostname_active?(hostname)
    site = where(hostname: hostname)
    site.exists? && site.first.active?
  end

  def active?
    subscription.active?
  end
end

class Subscription < ActiveRecord::Base
  belongs_to :site

  def active?
    (starts_at..ends_at).cover?(Date.current)
  end
end

describe Site do
  let(:site) { Fabricate.build(:site) }

  describe "#hostname_active?" do
    it "Returns true if site with hostname exists & is active" do
      described_class.stub_chain(:where, :exists?).and_return(true)
      described_class.stub_chain(:where, :first) { site }
      site.stub(:active?).and_return(true)
      described_class.hostname_active?('www.example.com').should be_true
    end

    it "Returns false if site with hostname doesn't exist" do
      described_class.stub_chain(:where, :exists?).and_return(false)
      described_class.stub_chain(:where, :first) { site }
      site.stub(:active?).and_return(false)
      described_class.hostname_active?('www.example.com').should be_false
    end

    it "Returns false if site is not active" do
      described_class.stub_chain(:where, :exists?).and_return(true)
      described_class.stub_chain(:where, :first) { site }
      site.stub(:active?).and_return(false)
      described_class.hostname_active?('www.example.com').should be_false
    end
  end
end

Where the related subscription determines if the Site is active or not, I use the method hostname_active? both as a constraint in routes and also in other classes where I need to determine if it a) exists, and b) is active.

Taken from another question on SO:

Tell-don’t-ask basically means you shouldn’t query an object about it state, make a decision based on it’s state and then tell the same object what to to. If the object has all the information it needs, it should decide for itself.

While I don’t do that, my code does feel pretty coupled, both in regards to the coupling between site & subscription, but also the coupling to ActiveRecord, which makes it hard to test without touching the database.

How would you structure it to avoid asking the related subscription in order to determine the site’s state? And also, would you consider this to be a violation of tell don’t ask?

Answer 1

Using ActiveRecord, you’re going to have some coupling, and it’s okay, and what you are doing does not violate LOD. You can denormalize the active field to keep it on the site itself, but I wouldn’t do that.

One thing that I would change is to eager load the subscription.

#Just showing changes

class Site < ActiveRecord::Base
  scope :active, includes(:subscription).merge(Subscription.active)
  has_one :subscription, dependent: :destroy

  def self.hostname_active?(hostname)
    active.where(hostname: hostname).exists?
  end
end

class Subscription < ActiveRecord::Base
  scope :active, where(arel_table[:starts_at].lteq(Date.current), arel_table[:ends_at].gteq(Date.current))
end

At the very least, that will keep you from having to do two queries to determine if a hostname is active.

As far as stubbing ActiveRecord, I don’t normally see that happening. The generally accepted practice is to use fixtures or factories to build your test objects. Personally, I use FactoryGirl: https://github.com/thoughtbot/factory_girl_rails.

In your case, I would have factories like:

FactoryGirl.define do
  factory :subscription do
    site
    factory :active_subscription do
      starts_at { Date.today.beginning_of_month }
      ends_at { Date.today.end_of_month }
    end

    factory :inactive_subscription do
      starts_at { Date.today.beginning_of_month - 3.months }
      ends_at { Date.today.end_of_month - 3.months }
    end
  end
end

FactoryGirl.define do
  factory :site do
    sequence(:hostname, 1000) {|h| "site#{h}.example.com" }
    factory :active_site do
      after(:create) do |site|
        FactoryGirl.create(:active_subscription, site: site)
      end
    end
    factory :inactive_site do
      after(:create) do |site|
        FactoryGirl.create(:inactive_subscription, site: site)
      end
    end
  end
end

That would allow my specs to look like:

describe Site do 
  describe "Active site" do
    subject(:site) { FactoryGirl.create :active_site }
    its(:active?) { should eq(true) }
  end

  #etc...
end