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