<?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>Fire-and-Forget on Tarragon</title><link>https://tarrragon.github.io/blog/tags/fire-and-forget/</link><description>Recent content in Fire-and-Forget on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 17 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/fire-and-forget/index.xml" rel="self" type="application/rss+xml"/><item><title>Fire-and-Forget Orchestration（射後不理編排）</title><link>https://tarrragon.github.io/blog/testing/knowledge-cards/fire-and-forget-orchestration/</link><pubDate>Fri, 17 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/testing/knowledge-cards/fire-and-forget-orchestration/</guid><description>&lt;p>Fire-and-forget 編排是呼叫後不等待完成的執行形態：主方法觸發一組背景動作後立刻返回，背景動作在獨立的排程中繼續。這個時序落差是&lt;a href="https://tarrragon.github.io/blog/testing/knowledge-cards/flow-test/" data-link-title="Flow Test（流程測試）" data-link-desc="在假後端上驅動真實前端服務鏈、斷言散佈於業務旅程各階段的測試形態；與 unit / integration / E2E 的邊界劃分">流程測試&lt;/a>中「單跑綠、合跑紅」型 flaky 的常見根因——斷言假設「方法返回＝流程完成」，實際上方法只承諾「請求已送出」。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Fire-and-forget 是編排層的設計選擇，常見於刻意的 UX 決策（結帳成功後先解鎖畫面、收尾動作在背景執行）。它與非同步程式的其他時序問題（callback 順序依賴、事件到達順序）同屬 &lt;a href="https://tarrragon.github.io/blog/testing/05-test-design-judgment/flaky-test-root-cause/" data-link-title="Flaky test 根因分類" data-link-desc="計時依賴 / 環境差異 / 資源競爭 / 非確定性輸出 — 四類 flaky test 根因的辨識和處理策略">flaky test 根因分類&lt;/a>的計時依賴類，區別在於根因不是「等太短」而是「根本沒等」。同一時序落差反覆出現的測試，常被送進 &lt;a href="https://tarrragon.github.io/blog/testing/knowledge-cards/quarantine/" data-link-title="Quarantine（隔離）" data-link-desc="把已知 flaky 的測試從主要執行路徑移開、保留修復壓力的治理機制；與 skip 的語意差異在於 quarantine 有負責人和回收期限">quarantine&lt;/a>：先隔離觀察、依根因分類排修復優先序。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>同一條測試單獨跑通過、與其他測試檔合跑失敗，且失敗在「狀態尚未更新」或「副作用尚未發生」的斷言上。典型案例：結帳流程收尾（列印、狀態清理、資料同步）沒有被 await，測試斷言在收尾完成前執行（&lt;a href="https://tarrragon.github.io/blog/testing/cases/fire-and-forget-test-race/" data-link-title="T.C8 fire-and-forget 編排讓測試單跑綠、合跑紅" data-link-desc="結帳成功後的收尾動作（列印、狀態清理、資料同步）沒有被 await — 測試斷言與收尾動作賽跑，單獨執行時碰巧贏、整批執行時排程不同就輸；競態本身也揭露了產品的時序特性">T.C8&lt;/a>）。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>測試策略是輪詢終態取代固定等待：定義「完成」的可觀察條件（狀態欄位值、計數器到位），輪詢直到條件滿足或超過上限次數。固定 sleep 只是把賽跑的起跑線挪後，不同環境的排程速度不同，問題會再次出現。修法的選擇取決於 fire-and-forget 是否為刻意的產品設計——是的話改測試等待策略並記錄時序特性，改成可等待的則直接修正編排。劇本模板在&lt;a href="https://tarrragon.github.io/blog/testing/01-test-strategy-layers/semantic-fake-backend/" data-link-title="語意級假後端與流程測試" data-link-desc="bug 的成因是對後端行為的假設錯誤、由測試餵資料的 stub 驗證不出來時：建一個持有狀態、模擬已證實後端行為的假後端（test double 分類的 fake），讓流程測試走完整的多服務互動鏈">語意級假後端與流程測試&lt;/a>章。&lt;/p></description><content:encoded><![CDATA[<p>Fire-and-forget 編排是呼叫後不等待完成的執行形態：主方法觸發一組背景動作後立刻返回，背景動作在獨立的排程中繼續。這個時序落差是<a href="/blog/testing/knowledge-cards/flow-test/" data-link-title="Flow Test（流程測試）" data-link-desc="在假後端上驅動真實前端服務鏈、斷言散佈於業務旅程各階段的測試形態；與 unit / integration / E2E 的邊界劃分">流程測試</a>中「單跑綠、合跑紅」型 flaky 的常見根因——斷言假設「方法返回＝流程完成」，實際上方法只承諾「請求已送出」。</p>
<h2 id="概念位置">概念位置</h2>
<p>Fire-and-forget 是編排層的設計選擇，常見於刻意的 UX 決策（結帳成功後先解鎖畫面、收尾動作在背景執行）。它與非同步程式的其他時序問題（callback 順序依賴、事件到達順序）同屬 <a href="/blog/testing/05-test-design-judgment/flaky-test-root-cause/" data-link-title="Flaky test 根因分類" data-link-desc="計時依賴 / 環境差異 / 資源競爭 / 非確定性輸出 — 四類 flaky test 根因的辨識和處理策略">flaky test 根因分類</a>的計時依賴類，區別在於根因不是「等太短」而是「根本沒等」。同一時序落差反覆出現的測試，常被送進 <a href="/blog/testing/knowledge-cards/quarantine/" data-link-title="Quarantine（隔離）" data-link-desc="把已知 flaky 的測試從主要執行路徑移開、保留修復壓力的治理機制；與 skip 的語意差異在於 quarantine 有負責人和回收期限">quarantine</a>：先隔離觀察、依根因分類排修復優先序。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>同一條測試單獨跑通過、與其他測試檔合跑失敗，且失敗在「狀態尚未更新」或「副作用尚未發生」的斷言上。典型案例：結帳流程收尾（列印、狀態清理、資料同步）沒有被 await，測試斷言在收尾完成前執行（<a href="/blog/testing/cases/fire-and-forget-test-race/" data-link-title="T.C8 fire-and-forget 編排讓測試單跑綠、合跑紅" data-link-desc="結帳成功後的收尾動作（列印、狀態清理、資料同步）沒有被 await — 測試斷言與收尾動作賽跑，單獨執行時碰巧贏、整批執行時排程不同就輸；競態本身也揭露了產品的時序特性">T.C8</a>）。</p>
<h2 id="設計責任">設計責任</h2>
<p>測試策略是輪詢終態取代固定等待：定義「完成」的可觀察條件（狀態欄位值、計數器到位），輪詢直到條件滿足或超過上限次數。固定 sleep 只是把賽跑的起跑線挪後，不同環境的排程速度不同，問題會再次出現。修法的選擇取決於 fire-and-forget 是否為刻意的產品設計——是的話改測試等待策略並記錄時序特性，改成可等待的則直接修正編排。劇本模板在<a href="/blog/testing/01-test-strategy-layers/semantic-fake-backend/" data-link-title="語意級假後端與流程測試" data-link-desc="bug 的成因是對後端行為的假設錯誤、由測試餵資料的 stub 驗證不出來時：建一個持有狀態、模擬已證實後端行為的假後端（test double 分類的 fake），讓流程測試走完整的多服務互動鏈">語意級假後端與流程測試</a>章。</p>
]]></content:encoded></item></channel></rss>