<?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>接線測試 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E6%8E%A5%E7%B7%9A%E6%B8%AC%E8%A9%A6/</link><description>Recent content in 接線測試 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%8E%A5%E7%B7%9A%E6%B8%AC%E8%A9%A6/index.xml" rel="self" type="application/rss+xml"/><item><title>Wiring Test</title><link>https://tarrragon.github.io/blog/ddd/knowledge-cards/wiring-test/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/ddd/knowledge-cards/wiring-test/</guid><description>&lt;p>接線測試（wiring test）只回答一個問題：&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/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter&lt;/a> 了沒。做法是讓組裝路徑保持零 override——每個 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/dependency-injection/" data-link-title="Dependency Injection" data-link-desc="物件的依賴該由誰提供、測試怎麼換掉真實依賴時使用。依賴注入把「建構依賴」跟「使用依賴」分成兩個責任——使用方宣告需要什麼、提供方在組裝時決定給什麼。">依賴注入&lt;/a> 的注入項真實解析、路由表真實導航、UI 事件真實觸發——功能邏輯的對錯留給行為測試。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>一個測試通過時能證明的事（&lt;a href="https://tarrragon.github.io/blog/ddd/" data-link-title="DDD 領域驅動設計指南" data-link-desc="領域模型的理論與判準層：一袋欄位還是領域模型、什麼時候值得建 entity、不變式該落在哪一層強制、狀態轉換怎麼留下稽核軌跡、建構路徑怎麼設計。語言無關，實作限制路由到各語言模組。">本模組&lt;/a> 稱「證言」）由執行環境決定：在 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/test-seam/" data-link-title="Test Seam" data-link-desc="測試想把真實依賴換成替身、該從哪裡換時使用。seam 是不修改程式本體就能替換其中一段行為的位置——介面加注入點是物件導向最常見的形式。">test seam&lt;/a> 換上 mock 之後、綠燈對組裝再無證明力，接線測試因此是測試層面組裝證言的唯一來源（編譯期生成組裝碼的生態、編譯器先接住「缺實作」一類，其餘仍歸這裡）。跟端對端測試的分工是範圍換速度：E2E 在目標平台連行為一起驗、接線測試只驗接線，換取在 host 環境（開發機、非目標裝置）快速且確定地執行。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>個別測試用 override 是正當的 seam 用法；訊號要看專案層級——連一個零 override 的解析測試都沒有時、組裝處於無人作證的狀態。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>零 override 的邊界是組裝路徑：domain 到入口之間不替換任何一段、最外圈的 infrastructure（遠端服務這類）可以在邊界替換。回傳假值的 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/placeholder/" data-link-title="Placeholder" data-link-desc="「開發中」頁、空 callback、拋出例外的注入項該怎麼管理時使用。佔位是先立介面後補實作的合法中間態——它的失效讓測試綠燈、比文件層約束更靜默。">佔位&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>接線測試（wiring test）只回答一個問題：<a href="/blog/ddd/knowledge-cards/port/" data-link-title="Port" data-link-desc="判斷介面該宣告在哪一層、依賴方向該朝哪時使用。port 是 domain 對外宣告的介面——需求用領域語言說完、技術細節留在實作端。">port</a> 插上 <a href="/blog/ddd/knowledge-cards/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter</a> 了沒。做法是讓組裝路徑保持零 override——每個 <a href="/blog/ddd/knowledge-cards/dependency-injection/" data-link-title="Dependency Injection" data-link-desc="物件的依賴該由誰提供、測試怎麼換掉真實依賴時使用。依賴注入把「建構依賴」跟「使用依賴」分成兩個責任——使用方宣告需要什麼、提供方在組裝時決定給什麼。">依賴注入</a> 的注入項真實解析、路由表真實導航、UI 事件真實觸發——功能邏輯的對錯留給行為測試。</p>
<h2 id="概念位置">概念位置</h2>
<p>一個測試通過時能證明的事（<a href="/blog/ddd/" data-link-title="DDD 領域驅動設計指南" data-link-desc="領域模型的理論與判準層：一袋欄位還是領域模型、什麼時候值得建 entity、不變式該落在哪一層強制、狀態轉換怎麼留下稽核軌跡、建構路徑怎麼設計。語言無關，實作限制路由到各語言模組。">本模組</a> 稱「證言」）由執行環境決定：在 <a href="/blog/ddd/knowledge-cards/test-seam/" data-link-title="Test Seam" data-link-desc="測試想把真實依賴換成替身、該從哪裡換時使用。seam 是不修改程式本體就能替換其中一段行為的位置——介面加注入點是物件導向最常見的形式。">test seam</a> 換上 mock 之後、綠燈對組裝再無證明力，接線測試因此是測試層面組裝證言的唯一來源（編譯期生成組裝碼的生態、編譯器先接住「缺實作」一類，其餘仍歸這裡）。跟端對端測試的分工是範圍換速度：E2E 在目標平台連行為一起驗、接線測試只驗接線，換取在 host 環境（開發機、非目標裝置）快速且確定地執行。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>個別測試用 override 是正當的 seam 用法；訊號要看專案層級——連一個零 override 的解析測試都沒有時、組裝處於無人作證的狀態。</p>
<h2 id="設計責任">設計責任</h2>
<p>零 override 的邊界是組裝路徑：domain 到入口之間不替換任何一段、最外圈的 infrastructure（遠端服務這類）可以在邊界替換。回傳假值的 <a href="/blog/ddd/knowledge-cards/placeholder/" data-link-title="Placeholder" data-link-desc="「開發中」頁、空 callback、拋出例外的注入項該怎麼管理時使用。佔位是先立介面後補實作的合法中間態——它的失效讓測試綠燈、比文件層約束更靜默。">佔位</a> 解析得了、導航也會發生、在接線測試眼中是正常構件，要靠行為斷言或發版冒煙走查。這條界線在應用程式層怎麼守、<a href="/blog/ddd/composition-root-reachability/" data-link-title="組裝層的可達性" data-link-desc="行為測試全綠、功能在實機上沒有入口的失效形態出現時使用。mock 換掉的正是組裝，組裝完成與否在行為測試裡沒有證言；把可達性當成組裝層的不變式，在測試、發版與設計文件各給一個強制點。">組裝層的可達性</a> 有完整推導。</p>
]]></content:encoded></item></channel></rss>