新功能: TestSprite CLI 現已上線!

驗證迴圈裡的裁判,而不是又一個玩家。

在 Claude Code、Cursor 或 Codex 裡,您不需要打 CLI 參數——只要說:「幫這個 repo 設定 TestSprite,建立一組起始測試套件,然後對最重要的流程跑一次冒煙測試。」代理會讀懂您的路由與處理函式,建立測試,並執行它們——這是對它自己成果的第二道、獨立的檢查,而不是又一份您得盲目相信的草稿。

直接從 CLI 接入 8 種編碼代理

ClaudeCursorCopilotCodexWindsurfClineAntigravityKiro
說「用 TestSprite 驗證這個變更,再說完成」,而且要說到做到。一份寫好但沒執行的測試計畫,並不滿足這個指令。只有真正跑出來的結果才算——通過,或失敗。

「幫這個 repo 設定 TestSprite,建立一組起始測試套件」

代理會讀懂您的路由、處理函式與關鍵流程,建立一個專案,並撰寫大約 8 到 15 個帶有具體、可觀察斷言的測試——一次批次建立,不是一個一個打字。

「用 TestSprite 驗證這個變更,再說完成」

把測試執行到有結果——通過或失敗——而不是停在寫好的計畫。寫一個測試,和真正執行它,不是同一回事。

「幫結帳的正常路徑建立一個測試,並執行到有結果」

隨需為單一流程做針對性的覆蓋,而且和整套測試一樣,遵守「執行它,不要只是寫草稿」的原則。

建議您所需要的

失敗包——根本原因、螢幕截圖、DOM 快照、修復建議——是結構化的 JSON,讓代理可以自行解析,決定下一步該怎麼做,不需要人插手在中間。

You: "Set up TestSprite for this repo and seed a starter test suite,
      then smoke-run the most important flow."

# the agent runs this on your behalf — you never type it:
$ testsprite setup
$ testsprite test create-batch starter-suite.json
  ✓ 11 tests created from your routes and handlers

$ testsprite test run --project prj_8f2a --ids TC_checkout,TC_login --wait
  ✓ TC_checkout_happy_path   passed
  ✓ TC_login_success         passed

「寫好」不等於「做完」

說「執行到有結果」,而且要說到做到——一份存在但從未執行過的測試計畫,並不滿足這個指令。只有通過或失敗才算,而每個失敗都會以結構化包的形式回來,讓代理自己就能採取行動。

為無人看管的執行而打造

先讀懂您的程式碼庫

上手技能會在寫下第一個測試之前,先掃描您的路由、處理函式與關鍵流程——覆蓋範圍從您產品實際的行為出發,而不是用猜的。

穩定性評分

testsprite test flaky <testId> 會在代理耗費一次修復嘗試在錯誤的問題上之前,告訴它這次失敗是真正的回歸,還是不穩定的測試。

免費社群版

提供免費社群版,讓所有人都能使用。

執行中途取消

testsprite test cancel <runId> 在代理——或您——判斷不需要時,立刻停止一次進行中的執行。

全球企業信賴

"TestSprite 提供豐富的測試案例生成、清晰的結構和易於閱讀的程式碼。它還支援簡單的線上調試,並能夠透過生成新的測試案例快速擴展。"

"TestSprite 的自動化幫助我們減少了大量的手動工作。開發人員可以更容易地在開發過程早期發現並解決錯誤。"

常見問題

我實際上要說什麼才能設定好這一切?

在 Claude Code、Cursor,或其他支援的代理裡:「幫這個 repo 設定 TestSprite,建立一組起始測試套件,然後對最重要的流程跑一次冒煙測試。」剩下的交給代理處理——不需要背任何參數。

「建立一組起始測試套件」具體來說是什麼意思?

代理會讀懂您的程式碼庫——路由、處理函式、關鍵流程——建立一個 TestSprite 專案,撰寫大約 8 到 15 個帶有具體、可觀察斷言的測試,批次建立它們,然後只執行 2 到 3 個價值最高的正常路徑,而不是整套測試。

為什麼編碼代理不能自己測試自己的程式碼就好?

可以,但那等於是自己批改自己的作業——它的測試會繼承它對需求的任何誤解。testsprite 在另一個獨立的環境中執行,驅動真實瀏覽器或發出真實 API 請求,因此能抓到自我測試在結構上抓不到的那類錯誤。

要怎麼確保代理不會只是寫好一個測試就說完成了?

說「用 TestSprite 驗證這個變更,再說完成」,或是「執行到有結果」。這樣的措辭很重要——一份寫好但沒執行的計畫並不滿足它,只有真正的通過或失敗才算。

失敗時,代理拿到什麼?

一個結構化的 JSON 結果,包含完整的包:失敗步驟、螢幕截圖、DOM 快照、根本原因假設、修復建議——它嘗試修復時所需要的一切,不必先問人。

這需要 CI 嗎,還是可以在單人的夜間執行中使用?

都可以。不管是作為 GitHub Actions 裡的一個步驟,還是在您自己機器上一個長時間執行的單一代理工作階段裡,都是同一套 CLI。

給您代理的迴圈一個誠實的裁判。