The tools, grouped by what they answer.
Each tool queries one recording, from your coding agent (MCP), your editor (LSP) or the command
line.
The recorder, the editor's type hints and five tools are free: verify_mock,
what_calls, what_it_receives, who_actually_answered and
where_nil_comes_from. Every other tool on this page is Pro.
A Pro tool runs on your laptop against the same recording and needs a licence, which starts with
a trial. Every tool runs today against the example Rails app that each tool page quotes, and
the roadmap lists what is planned.
Test intelligence
verify_mock
Stubs that disagree with the real object. Compares what each stub in a spec returns with what the real method returned in the recording, and reports the stubs that return a class the real method did not.
See more →split_interface
The role interfaces in a class. Groups a class's public methods by which callers used them in the recording, and lists each group as a role interface to extract.
See more →dead_api
Find dead public API. The public methods that no caller reached in any recorded run, including those whose only caller is their own spec. Shown as a hint in your editor.
See more →unit_test_candidates
Which methods to test first. Every recorded method ranked by how many distinct callers it has and how many calls away the nearest spec is, to choose which untested code gets a test first.
See more →how_to_reach
The setup a method needs. The collaborators and the call path that put an object into the state a method needs, taken from a recorded run. Use it to write setup for tests that use real objects in place of doubles.
See more →observed_shape
The interface a call depends on. The messages your code sends to a value, read from recorded runs. They are the interface a call depends on, whether or not anyone declared it.
See more →testing_pyramid
Boundaries crossed through doubles alone. The calls between classes that your specs make through a double alone, with how many specs stub each one and how often your recorded app traffic made it for real, plus the number of examples in each spec directory.
See more →specs_that_reach
Run only the specs that reach your change. The spec examples whose recorded runs reach a method. After a change you rerun those examples alone, and the red-green loop takes seconds.
See more →how_far_it_reached
How far each spec example reached. For each spec example, the number of classes its recorded call tree touched and how deep the calls went. A unit spec that reaches fourteen classes is an integration test.
See more →Ask the call graph
what_calls
The callers of a method. Every caller of a method in the recorded runs, with the file and line of each call and how often it was made, including calls made through public_send. what_it_calls lists the methods it calls.
See more →how_it_got_here
How execution got here. The call chains that reached a method, in call order, taken from recorded runs. It is the stack trace you'd have got if the method had raised, for every route into it.
See more →where_time_goes
The call chains that run most often. The most-travelled call chains, ranked by how often they ran in the recording, so you can cache and optimise the chains with the most calls.
See more →what_a_change_touches
What a signature change affects. For each caller of a method, the argument classes it passed and the messages it sent to the return value, so you can see which callers a signature change affects before you make it.
See more →what_it_receives
What a method receives. For each argument of a method, the classes it was given in recorded calls and the messages the method sent to it.
See more →who_actually_answered
The classes that answered a call. At a duck-typed call site, the concrete classes that received the message in recorded runs, and how often each did. In an editor it answers go to implementation from the recording.
See more →where_nil_comes_from
Where nil comes from. The methods that returned nil and the arguments that received nil in recorded runs, logged as NilClass and tied to the errors that followed, including nil returns that a declared return type rules out.
See more →whats_looping
N+1 and hot loops. Call sites that ran many times in one call tree, ranked by repeats, with whether each one called many different objects, as an N+1 query does, or asked one object the same thing repeatedly.
See more →Software design
feature_envy
Find methods that belong on another class. A method that sends most of its calls to another object and few to its own. The report names the object to move it onto, using recorded call counts.
See more →relocate_file
Which file should move where. Two files that call each other often and are directories apart. The report names the folder they belong in, weighted by recorded call traffic and the distance between them.
See more →break_cycle
Cut a dependency cycle. The files or namespaces that form a dependency cycle at runtime. Each cycle is marked with its lowest-traffic edge, which is the cheapest one to cut.
See more →stabilize_dep
Dependencies that run against stability. A stable namespace, one with many callers and few dependencies, calling into a less stable one. Instability is computed from recorded calls, and the report lists the call sites to move or to put behind an abstraction.
See more →split_package
The parts of a namespace each consumer uses. Groups the classes in a namespace by which outside classes called them, and reports the groups that share no consumer as the lines to split the namespace along.
See more →check_diff
Check the methods a diff changed. Given a base ref, it reports the findings the changed methods introduced: a stub that no longer matches the real method, a dependency cycle, feature envy.
See more →The software design report, with a worked example →
Every tool above runs on your laptop, and your recordings stay there. Five are free and the rest need a Pro licence. Install the free ones → · Ask for a trial →
Across every app run Pro
find_implementers
Real classes that answer a set of messages. Searches your recorded runs for a class whose instances answered a required message set, so you can use it in place of a double that returns the wrong thing.
See more →prod_dead_api
Public methods no app run called. The public methods that no recorded app run calls. It counts request and job trees and leaves spec trees out, so a call from a method's own spec does not count as a caller.
See more →coupling_map
Coupling measured from app runs. Which modules and namespaces of your app call each other, and how many times, counted from recorded app runs.
See more →cypher
Query the graph in Cypher. Arbitrary Cypher over the shared graph, for a question that none of the other tools answers. Planned, with the hosted graph.
See more →
Today these tools pool the app runs in one recording. The hosted graph, which pools the runs
from every deploy, is built and is not open yet. cypher over it is planned.