91b951eb05
* Refactoring and extending article spam behavior Prior to this refactor, we were checking an Article's title for spaminess. This change now checks the Article's title and body_markdown. In addition, the encapsulates the regular expression implementations in favor of asking the Settings::RateLimit class to determine if the passed in text is "spammy". Furthermore, instead of having lots of inline logic within the article, this refactor introduces a `Spam::ArticleHandler` class. This helps tidy up the already busy Article specs by delegating the business logic of Spam handling to it's own class. There are further refactors for Comments and Users that would follow this pattern, but this change is more important to get out the door. Closes #15396 * Adding comments to clarify behavior of spam handling * Adding missing expectation to spec
33 lines
887 B
Ruby
33 lines
887 B
Ruby
require "rails_helper"
|
|
|
|
RSpec.describe Settings::RateLimit, type: :model do
|
|
describe ".trigger_spam_for?" do
|
|
subject { described_class.trigger_spam_for?(text: text) }
|
|
|
|
let(:text) { "text to test" }
|
|
|
|
context "when it matches a spam trigger term" do
|
|
before do
|
|
allow(described_class).to receive(:spam_trigger_terms).and_return(["to test"])
|
|
end
|
|
|
|
it { is_expected.to be_truthy }
|
|
end
|
|
|
|
context "when there are no spam trigger terms" do
|
|
before do
|
|
allow(described_class).to receive(:spam_trigger_terms).and_return([])
|
|
end
|
|
|
|
it { is_expected.to be_falsey }
|
|
end
|
|
|
|
context "when there are spam trigger terms but they don't match" do
|
|
before do
|
|
allow(described_class).to receive(:spam_trigger_terms).and_return(["in a hole in the ground"])
|
|
end
|
|
|
|
it { is_expected.to be_falsey }
|
|
end
|
|
end
|
|
end
|