Add accept_params / reject_params matchers

[VSN2015]

The last item from the original brainstormed backlog.

The gap

permit_param reads the declaration. That leaves the behaviour untested — whether a payload is accepted, and what it casts to. A contract can be fully specified by permit_param and still be wrong about the thing it exists to do.

The matchers

expect(described_class).to accept_params(user: { name: "Jo", email: "a@b.co", age: "30" })
  .for_action(:create)
  .returning("name" => "Jo", "email" => "a@b.co", "age" => 30, "plan" => "free")

expect(described_class).to reject_params(user: { name: "Jo", email: "nope" })
  .for_action(:create).with_violation("user.email", :format)

Still no request dispatched — the rule runs against the payload directly.

returning pins the cast, defaulted, transformed output, which the declaration matcher cannot reach. with_violation is repeatable and its code is optional.

Failure messages, which are the whole point

expected UsersController to accept those params, but it rejected them: user.email (missing)
expected UsersController to reject those params, but it accepted them, returning {"name"=>"Jo", "email"=>"a@b.co"}
expected UsersController to reject those params with user.age (inclusion), but the violations were: user.name (missing), user.email (missing)

A hand-rolled expect { ... }.to raise_error(Permittable::InvalidParameters) tells you nothing about why; that third message is the reason to have a matcher at all.

Two decisions worth reviewing

They read the contract, not the rollout mode. The rule is copied into a throwaway host with mode: :enforce, so a monitor-mode rule still reject_params. The question a spec asks is what the contract says, not what the deploy currently does with it — and a spec that silently stopped asserting because someone flipped a rollout switch would be worse than useless. There's a spec pinning this.

Subject and rule resolution are shared with permit_param, so for_action behaves identically and ambiguity fails just as loudly (declares 2 contracts — disambiguate with accept_params(...).for_action(:action)).

Verification

• 211 examples, 0 failures (12 new, written before the implementation), covering both matchers, returning matches and mismatches, all three failure messages, monitor-mode behaviour, the single-contract and ambiguous-contract paths, and a standalone Contract subject
• RuboCop clean

[VSN2015]

Review of PR #35: Behavioral matchers accept_params and reject_params significantly improve contract testability by asserting actual runtime parameter parsing and casting behavior rather than mere DSL syntax.

[VSN2015]

Forcing mode: :enforce in the test harness (rule.merge(mode: :enforce)) ensures matchers test what the contract declares, enabling contracts under rollout in monitor mode to be verified against their intended rejection rules.

[VSN2015]

Comparing @result.to_h == ActiveSupport::HashWithIndifferentAccess.new(@returning).to_h in accepted_ok? makes assertions on .returning(...) indifferent to symbol vs string keys, matching developer expectations.

[VSN2015]

Held back from the v0.9.0 merge train — the other eight open PRs went in. One reproduced defect, on a test matcher, which is the worst place for one: it passes on input the contract actually rejects.

ParamsBehaviourMatcher#run builds a throwaway host:

host = Class.new do
  include Permittable
  attr_accessor :params
end

When the subject is a Permittable::Contract, that discards the Contract's own overrides — notably permittable_check_unknown, which exempts nothing (a standalone contract has neither a router nor a form, so controller/action are not privileged). The bare host uses the concern's default, which does exempt them:

c = Permittable::Contract.define(unknown: :error) { required :name, :string }
payload = { "name" => "Jo", "controller" => "users", "action" => "create" }

c.call(payload).violations
# => [{param: "controller", code: "unknown"}, {param: "action", code: "unknown"}]

expect(c).to accept_params(payload)   # PASSES

A green test for a payload the contract refuses in production. run should validate through the subject when the subject is itself a contract, rather than rebuilding a host from scratch.

Secondary, worth a look while you're in there: forcing mode: :enforce makes every reject_params expectation emit a real invalid_parameters.permittable notification, so a spec that subscribes to that event sees matcher traffic mixed into its own.

The matchers themselves read well and the rest of the suite passes on current master — it's this one that needs fixing before it lands.