From d6c015900acedcd58efc165c2350934ae5600b2e Mon Sep 17 00:00:00 2001
From: Mark Burns <markburns@users.noreply.github.com>
Date: Tue, 26 Dec 2023 05:09:59 +0000
Subject: [PATCH] Update README.md

---
 README.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/README.md b/README.md
index 583f485..f64e88b 100644
--- a/README.md
+++ b/README.md
@@ -210,6 +210,34 @@ end
 
 ```
 
+### Interactor wiring specs
+Sometimes you have an interactor chain that fails because something is expected deeper down the chain and not provided further up the chain. 
+The existing way to solve this is with enough integration specs to catch them, hunting and sticking a `byebug`, `debugger` or `binding.pry` in at suspected locations and inferring where in the chain the wiring went awry.
+
+But we can do better than that if we always `promise` something that is later `expect`ed.
+
+In order to detect these wiring issues, stick a spec in your test suite like this:
+
+```ruby
+RSpec.describe 'InteractorWiring' do
+  it 'validates the interactors in the whole app', :aggregate_failures do
+    errors = Interactify.validate_app(ignore: [/Priam/])
+
+    expect(errors).to eq ''
+  end
+end
+```
+
+```
+    Missing keys: :order_id
+                        in: AssignOrderToUser
+                       for: PlaceOrder
+```
+
+This allows you to quickly see exactly where you missed assigning something to the context.
+Combine with lambda debugging `->(ctx) { byebug if ctx.order_id.nil?},` in your chains to drop into the exact
+location in the chain to find where to make the change.
+
 ### Sidekiq Jobs
 Sometimes you want to asyncify an interactor.