0

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?

Yeggeps
  • 2,055
  • 2
  • 25
  • 34

1 Answers1

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
Sean Hill
  • 14,978
  • 2
  • 50
  • 56
  • Hi Sean, that does also simplify the specs a bit, but I still need to stub the whole chain, or maybe I could avoid it somehow? `described_class.stub_chain(:active, :where, :exists?).and_return(false)` – Yeggeps Dec 04 '12 at 19:28
  • Is there any reason that you're wanting to stub that out? I don't generally see people stubbing out ActiveRecord methods when testing Rails applications. – Sean Hill Dec 04 '12 at 19:31
  • Mostly to keep the specs fast and not hitting the database all the time (it's a pretty big application, lot's of specs), but I might be thinking about it in the wrong way. – Yeggeps Dec 04 '12 at 19:45
  • Yeah, I mean, I don't think I would try to stub out the DB calls. They should represent a minimal increase in the time it takes to run the specs. Something I do is use Guard/Spork to run the specs as I work, reducing the time required to run the specs all at once. – Sean Hill Dec 04 '12 at 19:51
  • Thanks a lot for your thorough answer Sean. Also found [this](http://stackoverflow.com/questions/4277818/should-rails-units-tests-hit-database-or-not) and [this](http://stackoverflow.com/questions/1054989/why-not-hit-the-database-inside-unit-tests) questions helpful. – Yeggeps Dec 04 '12 at 20:17