Your agent guesses.
Your runtime knows.

Questions it answers

One recording answers questions about any method that ran.

Grep for .call matches every service object, proc and middleware in your app and its gems. For one call site, the recording lists the receivers that arrived there, with their classes and how often. Each tool asks one question of the same recording:

Asking the hosted graph anything else, in Cypher, is planned. See all the tools →

Example 2 · boundaries only doubles cross

Every unit spec passes, and no example runs the two classes together.

A stub with the wrong return is a fault in one double. A whole boundary between two classes can go untested the same way, whether you test first or after. Checkout's spec stubs the gateway and the gateway's spec tests the gateway alone, so every line is covered and no example runs the real Billing::Checkout calling the real Billing::Gateway. Coverage counts lines, so its report shows nothing missing.

Runtime Analysis sorts the recorded calls into the layers of your testing pyramid and lists the boundaries your specs cross through a double and in no other way. If you record your app too, the list is ranked by traffic. It then drafts a test that reaches a method, with setup taken from a recorded run.

The same finding is reported in your agent, your editor and the command line.

testing_pyramid(stubbed_only: true)
→ structuredContent: {
  summary: "3 boundaries only crossed via doubles",
  blocks: [ { type: "table",
    columns: [boundary, stubbed, real, app runs],
    rows: [
      ["Billing::Checkout#complete → Billing::Gateway#charge",
        5, 0, 58],
      ["(no recorded caller) → Billing::Gateway.new",
        2, 0, 0],
      ["(no recorded caller) → Account.find",
        1, 0, 0] ] }, … ] }

▶ reached by 3 examples · 58 app runs
def charge(amount)
  Receipt.new(id: "rc_…", amount: amount, paid: !amount.negative?)
end

$ ra testing_pyramid --stubbed-only

testing_pyramid
· 3 boundaries only crossed via doubles
  Billing::Checkout#complete → Billing::Gateway#charge  5  0  58
  (no recorded caller) → Billing::Gateway.new           2  0   0
  (no recorded caller) → Account.find                   1  0   0
  models     37
  billing     9
  requests    6
  finance     4
  services    4
  jobs        2
  reporting   2

ra scaffold then drafts a test whose setup comes from a recorded run. Your agent gets the same draft over MCP. An editor quick-fix that inserts it is planned.

$ ra scaffold Invoice#total
# drafted by ra scaffold from the recorded setup in spec/models/invoice_spec.rb:6
RSpec.describe Invoice do
  it "total" do
    invoice = build(:invoice)
    line_item = LineItem.new(sku: "…")
    invoice.add_line(item: line_item, quantity: 1)
    expect(invoice.total).to be_a(Money)
  end
end

Where you ask

In your agent, your editor, your terminal and CI.

One recording of Curriculum#unlocked_for, queried by your agent, shown in your editor, printed on the command line and checked in CI. The free tools and the editor's hover work in the same four places. observed_shape, the code lens and ra check shown here are Pro.

observed_shape(
  method: "Curriculum#unlocked_for"
)
→ structuredContent: {
  title: "Curriculum#unlocked_for",
  summary: "observed return",
  blocks: [
    { type: "table", rows: [
      ["return", "(no app messages)", Array],
      ["element", "#unlocked? #title", Book] ] },
    { type: "text", lines: [
      "· from 9 spec examples and 42 app runs"] } ] }

▶ reached by 9 examples · 42 app runs
def unlocked_for(student)
  eligible(student)
end

$ ra observed_shape \
    Curriculum#unlocked_for

Curriculum#unlocked_for
· observed return
  return   → (no app messages)  Array
  element  → #unlocked? #title  Book
· from 9 spec examples
  and 42 app runs

▸ ra check --since origin/main

check --since origin/main
· 13 findings introduced · 185 methods changed
✗ stub Curriculum#unlocked_for is a false positive
  spec/models/enrollment_spec.rb:9
  your stub returns [:geometry] Array<Symbol>
  the real one returns an Array whose elements receive #unlocked?, #title
  → return an Array of Book, as the real method did
  … 12 more

Error: Process completed with exit code 1

Your agent gets the same tools over MCP, so it can check a stub in the edit that introduced it. A Claude Code hook that runs verify_mock on every spec the agent writes is planned.

Each MCP tool is also a command. Run ra verify_mock on your suite, or ra check on a diff in CI, and a stub with the wrong return fails the build.

$ ra verify_mock spec/models/enrollment_spec.rb

verify_mock spec/models/enrollment_spec.rb
· 1 stub · 1 false positive · 0 unverified
✗ stub Curriculum#unlocked_for is a false positive
  spec/models/enrollment_spec.rb:9
  your stub returns [:geometry] Array<Symbol>
  the real one returns an Array whose elements receive #unlocked?, #title
  from 9 spec examples and 42 app runs
  a Symbol was never seen answering any of them
  → return an Array of Book, as the real method did

$ ra find_implementers '#unlocked?, #title'

real types responding to {#unlocked?, #title}
· 1 class
  Book  4  630  outside traced code (a factory or seeds)

Test first

In a test-first suite, each collaborator is recorded in its own spec.

The class you are about to write does not exist yet. Its collaborators do, and the tests from earlier cycles already ran them as real objects. When you mock Gateway in Checkout's spec, Gateway's own spec still runs the real class, so each double has a recording to be checked against.

The test-first walkthrough →

No tests

With no tests, record the running app.

Coverage and mutation testing report on code that a test runs. Runtime Analysis records whatever runs, so with the recorder on in development, staging or production, code with no specs is recorded too. A path that runs more often has more recorded calls behind each answer.

For a module with no specs you get its callers, the classes each method takes and returns, and the exception classes it raised. what_a_change_touches lists the callers a signature change would break. ra scaffold drafts a first spec from a recorded setup.

$ ra observe app/billing/billing/proration.rb

observe app/billing/billing/proration.rb
· 4 recorded methods
Billing::Proration.for  from 15 spec examples and 106 app runs
  callers   Invoice#total · Billing::Checkout#complete · Api::QuotesController#show · spec/billing/proration_spec.rb
  returns   Billing::Proration  → #amount #adjust
Billing::Proration#adjust  from 10 spec examples and 46 app runs
  callers   Invoice#total · spec/billing/proration_spec.rb
  returns   Money  → #cents #currency #to_ledger_s #to_s
  … 2 more

# when a method raised, observe lists the exception class and how often
$ ra scaffold Invoice#total   # drafts a spec from a recorded setup

Under load the recorder drops records and counts them, and it does not block your app. Production support is still being hardened: see the questions page.