An RSpec 3.13 spec stubs SmsGateway.deliver on the real class and still passes after deliver was renamed; what does verify_partial_doubles change, and what does it still miss?

## The failure mode A notification service calls `SmsGateway.deliver(to:, body:)`. Its spec avoids real network traffic with a **partial double**, a real class with one method replaced for the duration of the example: ```ruby allow(SmsGateway).to receive(:deliver).and_return("msg-42") ``` A refactor renames the class method to `SmsGateway.send_message`. Production now raises `NoMethodError` on every notification, yet the spec stays green: rspec-mocks installed a `deliver` method on `SmsGateway` for the example, so the code under test found exactly what it expected. The stub hid a real interface change. ## What the setting does `verify_partial_doubles` is an rspec-mocks configuration option: ```ruby RSpec.configure do |config| config.mock_with :rspec do |mocks| mocks.verify_partial_doubles = true end end ``` With it on, the rspec-mocks documentation says partial doubles get the same checks as `object_double`: 1. **Existence**: stubbing or expecting a method the object does not respond to fails when the stub is declared, with an error such as `SmsGateway does not implement: deliver`. A private method counts as existing, because the check asks `respond_to?(name, true)`. 2. **Call signature**: each call on the stubbed method is checked against the original method's parameters, so a missing required keyword raises `ArgumentError`. 3. **`with` constraints**: an argument list the real method could never accept fails when the expectation is declared. ## How the check decides that a method exists For a partial double there is a real object to ask, so rspec-mocks calls `respond_to?(name, true)` on it. Two consequences follow: - a method answered through `method_missing` counts as existing **if** the object's `respond_to_missing?` says so, unlike `instance_double`, which can only ask the class; - private methods count as existing, so verification does not stop you stubbing a private helper, which is usually a spec-design smell rather than something the setting polices. The signature check then reads the original method's parameters: required and optional positionals, required keywords, and whether it takes a splat. A method defined as `def deliver(*args)` accepts anything, so the arity check has nothing to catch. ## Version facts | Fact | RSpec 3.13 | |---|---| | Default inside rspec-mocks | `false` | | Generated `spec/spec_helper.rb` | sets it to `true` | | Stated plan | "will default to `true` in RSpec 4" (comment in the generated file) | The documentation gives the reason it defaults to off: backwards compatibility. Older suites that never ran `rspec --init` with a recent RSpec, or that replaced the generated file, may not have it, and that is worth checking first when a stubbed method turns out not to exist. ## What it still misses Verification compares names and signatures, nothing more: - **Return values** are unchecked. `and_return("msg-42")` passes even if the real method now returns a receipt object. - **Behaviour** is unchecked. A method that still exists but now raises for your inputs will not be noticed. - **Dynamically defined methods** that appear only at run time can make verification fail spuriously. `without_partial_double_verification { ... }` turns the check off just for the stubs declared inside the block, instead of for the whole suite. - **Pure doubles** are out of scope. A plain `double` is not a partial double; only `instance_double`, `class_double` and `object_double` verify it. - **String-named verifying doubles** verify only when the constant is loaded; `verify_doubled_constant_names = true` makes an undefined name an error, and the rspec-mocks docs recommend it for full-suite runs. ## Rolling it out to an old suite Turning the setting on in a large suite usually surfaces a batch of failures at once. Each is one of three things: 1. a **stale stub** for a method that was renamed or removed, which is the bug the setting exists to find; 2. an **arity mismatch**, often a stub whose `with` no longer matches the real keywords; 3. a **dynamic method** defined after the object is created, which calls for `without_partial_double_verification` around that stub or for defining the method explicitly. Fixing the first two is ordinary maintenance. The third should stay rare; if it is common, that is a sign the spec stubs framework internals rather than your own interfaces. ## Beyond configuration Even with every verification switch on, a green unit suite proves only that the stubs match signatures. A small number of specs that exercise the real `SmsGateway` against a sandbox or a recorded fixture are what prove the contract.