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?
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