<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>測試 Seam on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E6%B8%AC%E8%A9%A6-seam/</link><description>Recent content in 測試 Seam on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Mon, 13 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E6%B8%AC%E8%A9%A6-seam/index.xml" rel="self" type="application/rss+xml"/><item><title>Test Seam</title><link>https://tarrragon.github.io/blog/ddd/knowledge-cards/test-seam/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/ddd/knowledge-cards/test-seam/</guid><description>&lt;p>測試 seam 是不修改程式本體就能替換其中一段行為的位置——術語出自 Michael Feathers 的《Working Effectively with Legacy Code》。物件導向程式最常見的 seam 是介面加注入點：&lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/port/" data-link-title="Port" data-link-desc="判斷介面該宣告在哪一層、依賴方向該朝哪時使用。port 是 domain 對外宣告的介面——需求用領域語言說完、技術細節留在實作端。">port&lt;/a> 宣告需求、&lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/dependency-injection/" data-link-title="Dependency Injection" data-link-desc="物件的依賴該由誰提供、測試怎麼換掉真實依賴時使用。依賴注入把「建構依賴」跟「使用依賴」分成兩個責任——使用方宣告需要什麼、提供方在組裝時決定給什麼。">依賴注入&lt;/a> 提供替換的入口，測試在這裡把真實 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter&lt;/a> 換成 mock、讓 domain 邏輯脫離資料庫與網路單獨驗證。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>seam 是分層架構測試承諾的兌現機制：「domain 可以脫離 infrastructure 測試」的具體操作、就是在 seam 換上替身。DI 容器的 override（測試用替身蓋過註冊項）是 seam 的容器化形式；&lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/composition-root/" data-link-title="Composition Root" data-link-desc="依賴組裝、路由註冊該集中在哪、組裝斷裂去哪檢查時使用。composition root 是應用程式唯一的組裝起點——DI、路由、事件接線的集中處。">composition root&lt;/a> 集中的組裝、正是 seam 替換的對象。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>測試不碰 production 程式碼就能把資料庫、網路、時鐘換成替身，是 seam 工作中的訊號。想測某段邏輯必須連上真實服務、或得修改本體才塞得進替身，是 seam 缺席的訊號。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>seam 有一體兩面：替換掉的正是 production 的組裝、於是「組裝有沒有完成」在以 seam 為基礎的測試裡沒有證言（綠燈證明不了組裝完成）。mock 測試全綠與功能可用之間的缺口由 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/wiring-test/" data-link-title="Wiring Test" data-link-desc="行為測試全綠、還想知道組裝有沒有完成時使用。接線測試在組裝路徑零 override 的環境解析每個注入項、走真實路由表，只驗「port 插上了 adapter」。">接線測試&lt;/a> 補；這道影子的完整推導見 &lt;a href="https://tarrragon.github.io/blog/ddd/composition-root-reachability/" data-link-title="組裝層的可達性" data-link-desc="行為測試全綠、功能在實機上沒有入口的失效形態出現時使用。mock 換掉的正是組裝，組裝完成與否在行為測試裡沒有證言；把可達性當成組裝層的不變式，在測試、發版與設計文件各給一個強制點。">組裝層的可達性&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>測試 seam 是不修改程式本體就能替換其中一段行為的位置——術語出自 Michael Feathers 的《Working Effectively with Legacy Code》。物件導向程式最常見的 seam 是介面加注入點：<a href="/blog/ddd/knowledge-cards/port/" data-link-title="Port" data-link-desc="判斷介面該宣告在哪一層、依賴方向該朝哪時使用。port 是 domain 對外宣告的介面——需求用領域語言說完、技術細節留在實作端。">port</a> 宣告需求、<a href="/blog/ddd/knowledge-cards/dependency-injection/" data-link-title="Dependency Injection" data-link-desc="物件的依賴該由誰提供、測試怎麼換掉真實依賴時使用。依賴注入把「建構依賴」跟「使用依賴」分成兩個責任——使用方宣告需要什麼、提供方在組裝時決定給什麼。">依賴注入</a> 提供替換的入口，測試在這裡把真實 <a href="/blog/ddd/knowledge-cards/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter</a> 換成 mock、讓 domain 邏輯脫離資料庫與網路單獨驗證。</p>
<h2 id="概念位置">概念位置</h2>
<p>seam 是分層架構測試承諾的兌現機制：「domain 可以脫離 infrastructure 測試」的具體操作、就是在 seam 換上替身。DI 容器的 override（測試用替身蓋過註冊項）是 seam 的容器化形式；<a href="/blog/ddd/knowledge-cards/composition-root/" data-link-title="Composition Root" data-link-desc="依賴組裝、路由註冊該集中在哪、組裝斷裂去哪檢查時使用。composition root 是應用程式唯一的組裝起點——DI、路由、事件接線的集中處。">composition root</a> 集中的組裝、正是 seam 替換的對象。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>測試不碰 production 程式碼就能把資料庫、網路、時鐘換成替身，是 seam 工作中的訊號。想測某段邏輯必須連上真實服務、或得修改本體才塞得進替身，是 seam 缺席的訊號。</p>
<h2 id="設計責任">設計責任</h2>
<p>seam 有一體兩面：替換掉的正是 production 的組裝、於是「組裝有沒有完成」在以 seam 為基礎的測試裡沒有證言（綠燈證明不了組裝完成）。mock 測試全綠與功能可用之間的缺口由 <a href="/blog/ddd/knowledge-cards/wiring-test/" data-link-title="Wiring Test" data-link-desc="行為測試全綠、還想知道組裝有沒有完成時使用。接線測試在組裝路徑零 override 的環境解析每個注入項、走真實路由表，只驗「port 插上了 adapter」。">接線測試</a> 補；這道影子的完整推導見 <a href="/blog/ddd/composition-root-reachability/" data-link-title="組裝層的可達性" data-link-desc="行為測試全綠、功能在實機上沒有入口的失效形態出現時使用。mock 換掉的正是組裝，組裝完成與否在行為測試裡沒有證言；把可達性當成組裝層的不變式，在測試、發版與設計文件各給一個強制點。">組裝層的可達性</a>。</p>
]]></content:encoded></item></channel></rss>