docbrown/spec/models/async_info_spec.rb
Jeremy Friesen bcfbd523d4
Moving from user.trusted tests to policy tests (#17619)
The [`ArticlePolicy#moderate?`][1] method answers the questions around article
moderation.

At present this change does not introduce any significant changes (aside
from the JS logic loop).  The next "step" is to adjust the
`ArticlePolicy#moderate?` method to test if the user has a moderator
role.

Further, we'd need to see what is available on the action panel.

Related to forem/forem#17606

[1]:5ac3216a5a/app/policies/article_policy.rb (L160-L174)
2022-05-11 08:18:13 -04:00

26 lines
1,023 B
Ruby

require "rails_helper"
RSpec.describe AsyncInfo do
describe "#to_hash_for" do
subject(:async_info) { described_class.to_hash(user: user, context: context) }
let(:user) { create(:user) }
let(:feed_style_preference) { Settings::UserExperience.feed_style }
let(:context) { AsyncInfoController.new }
# Because of edge caching considerations, I'm short-circuiting that check. For the applicable
# controller, we should always have an authenticated user and it is not edge cached.
before { allow(context).to receive(:current_user).and_return(user) }
it "has a policies key with an array of policies", :aggregate_failures do
policies = async_info.fetch(:policies)
expect(policies.length).to be > 0
# All policy keys will have dom_class and forbidden
expect(policies.map(&:keys).uniq).to eq([%i[dom_class visible]])
expect(policies.map { |p| p.fetch(:dom_class) }.sort)
.to eq(%w[js-policy-article-create js-policy-article-moderate])
end
end
end