web3-testing

web3-testing 技能總覽

web3-testing 能做什麼

web3-testing 技能可協助代理設計並搭建以 Hardhat 與 Foundry 為核心的智慧合約測試工作流程。它適合那些需求不只停留在一般「幫我寫幾個 Solidity 測試」提示的團隊：單元測試、整合測試覆蓋、mainnet fork、fuzzing、gas 檢查，以及與驗證相關的設定，都在它的能力範圍內。

誰適合使用 web3-testing

這個 web3-testing 技能特別適合：

• 正在建立或升級測試套件的 Solidity 開發者
• 正從傳統 QA／測試自動化轉往 Web3 的工程師
• 需要用 fork 狀態做高擬真驗證的 DeFi 團隊
• 想快速取得有結構測試思路的審計人員或協議工程師

如果你只需要一個非常簡單的單元測試，或你的技術棧根本不使用 Hardhat 或 Foundry，那麼它的幫助就相對有限。

真正要完成的工作

大多數使用者不是來看理論，而是想從「我有合約，也知道有哪些風險點」走到「我有一份可信、可執行的測試計畫與起手測試」。web3-testing 的價值在於，它會把對話推向具體的測試配置與進階測試模式，而不是停留在泛泛而談的建議上；尤其是在 forked state、fuzzing、gas reporting，以及多層次測試策略這些一般提示常忽略的部分，特別有用。

web3-testing 與一般提示有何不同

和一般 coding prompt 相比，web3-testing 在以下幾點提供更強的指引：

• 如何在 Hardhat 與 Foundry 工作流之間做選擇
• 如何設定更貼近真實情境的網路與環境配置
• 如何涵蓋智慧合約常見的邊界與例外情況
• 如何針對 fork 後的鏈上狀態測試協議行為
• 如何加入 coverage、gas reporting 之類的品質訊號

安裝前要先知道的事

從 repository 訊號來看，這個技能的範圍偏窄但很實用：它主要是一份 SKILL.md 操作手冊，而不是附帶腳本、工具或大量參考資源的大型工具包。這代表它很容易採用，但你應該預期拿到的是指引與範例，而不是自動化能力。如果你想找的是一套內建 helper、可直接套用的測試框架，那它比較像是幫你思考與搭骨架的輔助，而不是可直接落地的 package。

如何使用 web3-testing 技能

web3-testing 的安裝方式

請從上層 repository 安裝此技能：

npx skills add https://github.com/wshobson/agents --skill web3-testing

由於 repo 路徑是 plugins/blockchain-web3/skills/web3-testing，你安裝的是一份聚焦的技能文件，而不是獨立的 npm 測試函式庫。

先讀這個檔案

請先從這裡開始：

• SKILL.md

這份文件才是這個技能真正的權威來源。技能目錄內沒有什麼實質的支援資料夾，因此不要預期在其他地方還藏有 helper 或額外資源。

你需要提供給 web3-testing 的輸入

web3-testing 在你提供以下資訊時效果最好：

• 合約用途
• 關鍵函式與存取控制
• invariants 或安全性性質
• 你偏好的工具鏈：Hardhat、Foundry，或兩者都用
• 外部依賴，例如 oracle、pool、token、proxy contract
• 你需要的是單元測試、整合測試、fork 測試、fuzzing，還是 gas 檢查

弱輸入範例：「Write tests for my contract.」

強輸入範例：「Using Foundry, create unit and fuzz tests for an ERC20 staking contract with reward accrual, admin-only parameter updates, pause behavior, and emergency withdrawal. Include revert-path coverage and invariants around total staked balances.」

把模糊目標轉成可用的提示

一個好用的 web3-testing usage 提示通常包含四個部分：

1. 技術棧
2. 合約介面／範圍
3. 風險區域
4. 想要的輸出格式

例如：

“Use the web3-testing skill to propose a test plan and starter files for a Hardhat project. Contract set: Vault.sol, Strategy.sol, OracleAdapter.sol. Focus on deposit/withdraw accounting, role restrictions, stale oracle handling, slippage boundaries, and upgrade safety. Include unit tests, one mainnet fork scenario, and gas reporter setup.”

這會比只要求「comprehensive tests」好得多，因為它明確告訴代理，在你的情境裡「完整」到底代表什麼。

有意識地選擇 Hardhat 或 Foundry

原始內容同時涵蓋兩套框架，因此你的提示應該明講要優先針對哪一套最佳化。

以下情況適合用 Hardhat：

• 你想用 JavaScript 或 TypeScript 撰寫測試流程
• 你的工作流高度依賴 plugin
• 你想在熟悉的 Node 環境中配置 coverage 與 gas reporter
• 你需要更容易和整體應用工具鏈整合

以下情況適合用 Foundry：

• 你想要更快的 Solidity 原生測試
• 你需要 fuzzing 與 invariant 類型的工作流
• 你想要更緊湊、以智慧合約為核心的開發迴圈

如果你的團隊兩者都有在跑，請明確說出來，並要求技能幫你拆分各自職責，而不是含糊地混在一起。

適合測試自動化的 web3-testing 工作流程

若是把 web3-testing for Test Automation 用在測試自動化場景，最穩健的流程通常是：

1. 先請它列出測試矩陣
2. 檢查有哪些失敗情境還漏掉
3. 再要求 setup／config 檔案
4. 產生 starter tests
5. 之後再用實際合約程式碼與 ABI 細節細化
6. 最後才補 fork 與 fuzz 層

這個順序可以避免一種很常見的失敗模式：代理產出看似能跑的測試，但其實沒有真正對應到你的協議風險。

web3-testing 特別擅長產出什麼

實務上，web3-testing 最有幫助的輸出包括：

• 初始的 hardhat.config.js 測試設定
• 測試類型拆解與分類
• 針對標準行為的 starter unit tests
• 適用於 DeFi 整合的 fork test 點子
• fuzzing 目標與 edge case 清單
• gas reporting 與 coverage 建議

它最適合被當作「結構化測試指引 + 程式骨架產生器」來使用。

哪些因素最常讓結果變差

最大的阻礙通常不是安裝問題，而是協議脈絡資訊不足：

• 沒有合約程式碼或函式清單
• 沒有說明關鍵 invariants
• 沒有解釋外部整合關係
• 只要求「full coverage」卻沒有優先順序
• 在同一個模糊請求裡混用多種框架假設

如果這些資訊缺漏，輸出很容易退化成通用 ERC20 式的測試建議，而不是針對你協議的測試自動化方案。

提升 web3-testing 輸出品質的實用提示格式

只要做得到，盡量使用這個結構：

• Repository context: framework、Solidity version、proxy pattern、package manager
• Contracts in scope: 檔名與各自責任
• Critical behaviors: deposits、liquidations、claims、rebase logic、governance
• Failure conditions: unauthorized access、rounding、reentrancy assumptions、stale data
• Desired artifacts: config、test plan、test file skeletons、mock strategy、fork scenario
• Constraints: 測試需保持 deterministic、避免依賴外部 API、CI 執行時間控制在 X 分鐘內

這種格式能讓 web3-testing guide 取得足夠精準的上下文，產出團隊能快速接手調整的內容。

只有在真實性重要時才用 fork 測試

這個技能把 mainnet forking 視為差異化優勢之一，但不是每個專案都需要。以下情況適合使用 fork 測試：

• 行為依賴真實協議狀態
• 與 DEX、借貸市場或價格餵價的整合會影響結果
• 用 mock 會掩蓋危險的邊界情況

以下情況可跳過或限制 fork 測試：

• CI 速度比真實性更重要
• 你的合約大多是相對獨立的商業邏輯
• 可重現性比模擬生態系環境更重要

採用前先驗證 web3-testing 產出的內容

在你合併任何由 web3-testing skill 產生的內容前，請先檢查：

• revert reason 與 access control 假設是否正確？
• token decimals 與 rounding 假設是否符合實際情況？
• fork block number 是否與測試情境對齊？
• gas 與 coverage plugin 是否和你的技術棧相容？
• 測試有驗證 invariants，還是只覆蓋 happy path？

這個技能確實能省時間，但協議層面的正確性，最後仍然必須靠你自己審查。

web3-testing 技能 FAQ

web3-testing 適合初學者嗎

適合，但前提是你已經理解基本的 Solidity 概念。這個技能可以加快 setup，並讓你看到較成熟的測試棧通常長什麼樣子。若是完全新手，你可能仍需要額外補上 Solidity 語法、部署流程與框架基礎。

web3-testing 只能用在 Hardhat 嗎

不是。這個技能明確同時涵蓋 Hardhat 與 Foundry。但它最能發揮效果的前提，是你要告訴代理優先聚焦哪個生態，而不是讓它自己猜。

web3-testing 和一般 AI 提示有什麼差別

一般提示往往只會回傳表層的單元測試。web3-testing 則更偏向完整的智慧合約測試策略：fork-based realism、fuzzing、gas checks、coverage 與環境設定。這讓它更適合真正在協議層做驗證，而不只是產出 demo 用的測試。

web3-testing 能幫忙處理 DeFi 協議嗎

可以。這正是它相對契合的使用情境之一，特別是當你需要針對接近真實狀態的整合測試時。請提供協議依賴、預期 invariants，以及你在意的具體使用者流程。

什麼情況不該使用 web3-testing

以下情況不建議使用 web3-testing：

• 你只需要一個一次性的 assertion
• 你的專案不是以 Solidity 或 EVM 為核心
• 你要的是內建 helpers 與 fixtures 的封裝框架
• 你手上沒有足夠的合約脈絡，無法定義有意義的測試目標

web3-testing 內含可直接執行的工具嗎

嚴格來說沒有。從 repository 可見的內容來看，它是以文件為主、附帶範例的技能，而不是打包好的腳本或可重複使用資產。請把它視為指引與生成輔助，而不是可安裝的測試框架。

如何把 web3-testing 用得更好

給 web3-testing 的是協議風險，不只是檔名

想提升 web3-testing usage 效果，最快的方法是直接說出你真正擔心的失敗模式：

• accounting drift
• price manipulation
• permission bypass
• bad upgrade initialization
• insolvency after extreme inputs

這會讓輸出從通用骨架，轉成以風險驅動的測試設計。

先要測試矩陣，再要程式碼

一個高槓桿的做法是：

1. 「List test categories and invariants.」
2. 「Now generate the highest-priority test skeletons.」
3. 「Now fill in mocks and edge cases.」

這樣可以減少浪費在錯方向上的程式碼，也能更早暴露理解偏差。

提供真實的合約介面

如果你直接貼上 function signatures、events、custom errors 與 storage constraints，web3-testing skill 產出的測試會強很多。少了這些資訊，它就可能自行腦補 setup 細節，或只能依賴寬泛假設。

把 happy path 與對抗性路徑分開

你可以要求技能把輸出組織成：

• happy-path functionality
• authorization checks
• boundary and rounding cases
• integration failures
• fork-specific scenarios
• fuzz or invariant candidates

這種結構更方便審查，也更利於規劃 CI。

用精確的狀態假設改善 mainnet fork 提示

如果你想讓 fork 測試輸出更可用，請補充：

• network name
• RPC environment variable name
• target block number
• 要 impersonate 或互動的合約
• 需要的餘額或 approvals
• 交易後預期狀態

沒有這些資訊時，fork 建議通常只會停留在概念層，後續還需要你手動清很多內容。

要留意的常見失敗模式

web3-testing 輸出最常出問題的幾種方式：

• 用不夠真實的 mock 取代關鍵整合行為
• coverage 看起來很廣，卻漏掉真正有資金風險的路徑
• framework config 與你現有 repo 衝突
• 該用單元測試就能更快更清楚解決的場景，卻硬套 fork 測試
• 過度著重 setup，卻沒有把 invariants 定義清楚

審查生成結果時，重點應該放在風險覆蓋，而不只是語法正確。

第一版不完整時，迭代通常比重來更有效

如果第一版結果已經接近，但還不夠完整，可以直接給這類修正回饋：

• 「Add revert-path tests for every admin function.」
• 「Convert these integration cases into Foundry fuzz tests.」
• 「Replace mocks with a fork-based scenario for the oracle dependency.」
• 「Prioritize accounting invariants over boilerplate deployment tests.」

多數情況下，這會比整份丟掉、重新從零下 prompt 得到更好的結果。

用 repository 專屬脈絡來強化 web3-testing

當你補充以下資訊時，這個技能會變得實用得多：

• 目前 repo 結構
• 已有的 fixtures 或 helper libraries
• CI 時間限制
• 是否已使用 forge-std、hardhat-toolbox，或自訂部署腳本
• 測試與 fixture 的命名慣例

這能讓代理依照你的 repository 調整輸出，而不是只生成孤立的範例。

高品質的 web3-testing 輸出應該長什麼樣子

好的 web3-testing 輸出，應該能提供你：

• 與協議風險直接對應的清楚測試計畫
• 符合你技術棧的 framework-specific setup
• 能對應真實函式與 invariants 的測試骨架
• 只在真正有價值的地方使用 fork 與 fuzz testing
• 清楚的後續步驟，讓生成出的內容能走向可維護的測試套件

如果輸出無法提升你的判斷品質，或沒有幫你省下實作時間，那通常不是去要求「更完整」就會解決，而是要先把輸入收斂得更精準。