沒穿方服

多年後才知道有 vim-test 這個專案，但看起來沒有我寫的好用，就沒關心了。

直到最近嘗試 vim-themis 測試框架，無法直接套以前的工具，才想來研究這個還算熱門的專案。

對應多種語言的 :TestNearest 是最大價值

專案 README 第一行寫著： A Vim wrapper for running tests on different granularities.

各種測試框架被定義為 test runner，例如 ruby 的 minitest、rspec，JS 的 jest、vitest、cypress。 能自動辨識處於哪個環境，然後在編輯特定檔案時（不一定要是測試檔本身），能找到對應測試然後執行，即使 runner 不支援 "Nearest"（只跑最接近游標的、最小粒度的測試）也有機會用搜尋湊出來，然後只測這個範圍。

持續收錄大家的貢獻，支援更多語言和框架，讓我們進入新專案時直接可用，就是它最棒的地方。

執行畫面要開在哪裡：strategy

至於跑測試的介面，例如用 :! 開、用 tmux 開、用 vim-dispatch 開，這些被定義為 strategy。

Strategy 就比較貧弱了，雖然提供了 34 種，但這個抽象並沒有提供額外能力（有幾個例外，能支援 quickfix 等），從實作 autoload/test/strategy.vim 可以看見，幾乎每個 strategy 都只是呼叫一個開啟指令就結束了。

最後我是直接指明 custom strategy，接到自己寫的 tmux 功能（暫未公開），才能取得「開在右邊、下面、新視窗、重用」這些能力。

let g:test#custom_strategies = {'tmux_window': function('TmuxTestStrategy')}
let g:test#strategy = 'tmux_window'

定義 g:test#strategy 還有一個好處，就是會跳過載入 autoload/test/strategy.vim，如果你只用其中一個 strategy，實在不必每次吃這個檔。

痛點：非制式的測試

現實世界中，很多專案的測試都有客製化，或者用一個 script 包裝過，例如 ./test/run.sh、npm run test，這時候用自動偵測的 runner 去跑反而是偏差的。

vim-test 提供的解法，簡單的狀況是指定 test#{runner}#executable（只改執行指令）或 custom transformation（只微調測試指令），再複雜就需要用到 custom runner 才能解決問題。 Custom runner 已經是在實作一個 runner，所以也會建議寫完貢獻回上游專案。 但就是因為需求處於「一次性的設計」和制式標準之間，所以問題就一直重複下去。

去年也有人提出相關議題，其中一步是增加了 generic runner： #820 Add support for generic command runner

後來又有一個想法是單發的 :TestCommand（討論後已 close）： #862 Add :TestCommand for one-off tests

目前我還沒想辦法改善，也許要支援一個測試情境本來就難，終究要弄一個 runner 或類似的東西。

實用函數 test#base#nearest_test()

在尋找 Nearest 的實作上，內部函數 test#base#nearest_test() 扮演關鍵角色，也比較難自己刻出來，某方面也是這個 plugin 的精華所在。

維護狀況良好

這個專案已經 11 年了，最初是一位捷克的 ruby 開發者 Janko Marohnić 啟動，現在也有其他人幫忙維護，處理 issue 很快，是健康可靠的專案。