kotlin-testing

kotlin-testing 技能總覽

kotlin-testing 是用來做什麼的

kotlin-testing 技能是一份實用指南，協助你在 Kotlin 專案中撰寫與改善測試。它聚焦在多數團隊真正需要的工作：選擇 Kotest 的風格、用 MockK 模擬相依元件、正確測試 coroutines，以及運用 property-based tests 和 Kover coverage，且不把測試程式碼寫成一堆樣板。

誰適合安裝

如果你正在為 Kotlin app 新增測試、想統一團隊的測試做法，或希望建立符合 TDD 的工作流程而且要貼近 idiomatic Kotlin，就適合安裝 kotlin-testing 技能。它特別適合 JVM Kotlin 專案中的開發者，因為你需要的是可重複使用的模式，而不是零散的測試提示。

最適合用在哪些情境

這個技能最適合測試自動化任務，而且目標是可靠的 unit 或 component 覆蓋，而不是端到端框架建置。當你需要寫第一個測試、重構脆弱的斷言，或想用 Kotlin 特有的方式理解如何透過 mocks 與 coroutines 隔離程式碼時，它會特別有幫助。

如何使用 kotlin-testing 技能

在你的工作區安裝 kotlin-testing

先依照這個技能的 repository 安裝流程操作，然後在請求測試程式碼之前，先把 agent 指向 skills/kotlin-testing 的 context。repo 中提供的基礎安裝指令是：
npx skills add affaan-m/everything-claude-code --skill kotlin-testing

要得到最佳結果，請把它安裝在 Kotlin 程式碼實際所在的同一個工作區，這樣技能就能直接對真實檔案、套件名稱與建置工具鏈發揮作用。

提供一個可測試的 Kotlin 目標

kotlin-testing 技能在你的提示詞明確指出一個具體目標和一個預期測試結果時，效果最好。好的輸入包含 class 或 function 名稱、你已經使用的 framework，以及任何限制，例如 coroutine 行為、mocking 規則或 coverage 門檻。

提示詞範例：
Use kotlin-testing to write Kotest tests for UserService.createUser. Mock the repository with MockK, cover success and duplicate-email failure paths, and keep the tests compatible with our Gradle/Kover setup.

先讀對的檔案

先從 SKILL.md 開始，再視情況檢查 README.md、AGENTS.md、metadata.json，以及任何存在的 rules/、resources/、references/ 或 scripts/ 資料夾。對這個 repo 來說，SKILL.md 是主要依據，所以最快的路徑是先讀它的 “When to Use”、“How It Works” 和 “Examples” 章節，再開始草擬提示詞。

用工作流程，不只是片段

這個 repo 是圍繞 test-first 流程來組織的：先辨識目標、寫 Kotest spec、mock 相依元件、執行失敗的測試、實作程式碼，最後用 ./gradlew koverHtmlReport 驗證 coverage。當你需要的是一套執行計畫，而不只是幾個範例斷言時，這個技能會更有價值。

kotlin-testing 技能 FAQ

kotlin-testing 只適合 TDD 嗎？

不是。TDD 是這個技能的預設工作流程，但這些模式也很適合回頭替既有的 Kotlin 程式碼補測試。如果你已經有實作程式碼，可以用這個技能補上聚焦的覆蓋率，並讓 mocks 更乾淨。

這會取代一般提示詞嗎？

當你需要 Kotlin 特有的決策時，它會比一般提示詞更有幫助：例如要選哪種 Kotest 風格、怎麼 mock coroutines、以及如何看待 coverage。一般提示詞也能寫測試，但 kotlin-testing 能減少在 framework 適配與測試結構上的猜測成本。

它適合初學者嗎？

可以，只要你能描述一個 Kotlin unit 或 class，並且想要一個有引導性的測試計畫。若你還不熟悉 build system、還沒有明確的測試目標，或你需要的是廣泛的架構建議而不是具體測試程式碼，它就沒那麼有幫助。

什麼情況下不該用 kotlin-testing？

不要把它拿來取代 browser automation、API contract testing，或非 Kotlin 的 testing stack。如果你的問題主要是基礎設施、容易不穩定的 integration 環境，或 test data 管理，那麼更廣泛的 test automation 技能會比 kotlin-testing 更適合。

如何改善 kotlin-testing 技能

提供比「寫測試」更完整的上下文

要讓 kotlin-testing 有更好的結果，關鍵是輸入要精準：被測 class、public methods、重要分支，以及你想沿用的既有測試風格。也請說明你想用 Kotest StringSpec、FunSpec 還是 BehaviorSpec，因為這會影響可讀性與結構。

先把硬性限制說清楚

如果你的程式碼用了 suspending functions、flows、private collaborators，或有嚴格的 coverage gate，請在生成前先講明。比如說：Use MockK for the repository, test this suspend function with coroutine test support, and keep the assertions compatible with Kover coverage goals.

要求涵蓋失敗路徑的測試

這個技能最有價值的地方，在於你要求的是 happy-path 與 failure-path 都要有，而不只是「一個會過的測試」。如果 function 可能回傳 null、丟出例外、重試，或驗證輸入，請明確指定這些情境，這樣產出的測試套件才真正能支援決策。

透過收緊測試設計來迭代

拿到第一版輸出後，再根據缺少的部分把提示詞收窄：邊界案例、命名慣例、fixture 設定，或不穩定的相依元件。kotlin-testing 最快的改進迴圈，就是先檢視生成的 spec，找出哪些地方過度 mock、哪些覆蓋不足，然後針對你仍需要的那一條分支，要求更精準的重寫。