# vim-test: Running Tests at Any Granularity Directly from Vim

> vim-test is a zero-dependency Vim plugin that wraps over 30 test runners across more than 20 programming languages. It autodetects the appropriate runner based on the project context and provides a unified set of commands for running tests at the file, suite, or nearest-test level.

**vim-test/vim-test** — Run your tests at the speed of thought

- Repository: https://github.com/vim-test/vim-test
- Stars: 3,164 · Forks: 409
- Language: Vim Script
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/vim-test-vim-test

## What vim-test Does and Who It Is For

vim-test is a Vim plugin that abstracts over running tests in any language from within the editor. Instead of switching to a terminal, typing the test command, and switching back, vim-test lets you trigger a test run with a single command from wherever your cursor is in the file. The plugin translates that command into the correct runner invocation for your language and project.

The README describes the core value as running tests on different granularities: you can run the specific test nearest to the cursor, all tests in the current file, or the full test suite. This granularity is consistent regardless of which language and test runner is in use, because vim-test provides a unified abstraction layer on top of each runner.

The target audience is Vim and Neovim users who write tests regularly and want the test workflow to feel as integrated as editing does.

## Runner Auto-Detection: Zero Configuration in Practice

The README states that zero configuration is required because vim-test follows a "Does the Right Thing" philosophy. When you invoke a test command, the plugin examines the current file and project context to determine which test runner to use. For a Python project with a pytest configuration file, it selects pytest. For a JavaScript project with a Jest configuration, it selects Jest. For a Go file, it detects gotest.

This auto-detection removes the need to configure a per-project runner setting. The README lists runner identifiers for each language, which are the internal names used by the plugin. JavaScript alone supports over 20 runner identifiers, including ava, cucumberjs, cypress, deno, jest, mocha, playwright, vitest, and bun. Having explicit identifiers means you can also set a runner manually if the auto-detection picks the wrong one for an unusual project layout.

The zero-dependency design means vim-test requires no additional Vim plugins or runtime libraries beyond the test runners themselves.

## Test Granularity and the Nearest-Test Polyfill

vim-test offers commands for running tests at three levels: the test nearest to the cursor, all tests in the current file, and the full test suite. The nearest-test command is the most useful during active development because it runs exactly the one test you are working on without executing the rest of the suite.

Not every test runner natively supports running a single test by cursor position. For those runners, vim-test implements a polyfill by constructing a regular expression based on the test name near the cursor and passing it to the runner as a filter. The README refers to this as "polyfills for nearest tests" and notes that it works by constructing regexes. This means the nearest-test command works consistently across runners regardless of whether the runner has a built-in mechanism for it.

The polyfill approach has a constraint: it depends on correctly identifying the test name from the source code. If a test framework uses a non-standard naming pattern, the regex construction may fail or match incorrectly.

## Strategies: Controlling How Test Commands Execute

A strategy in vim-test is the mechanism used to execute the generated test command. The README lists this as a configurable feature: different strategies cover different execution environments. A strategy might run the test command in a terminal window split inside Vim, in a background job, through a tmux pane, or in an external tool.

The strategy layer is separate from the runner layer. You can use any strategy with any runner. This separation is what makes the plugin flexible: someone who uses tmux can configure vim-test to send test commands to a tmux pane, while someone who prefers an integrated terminal can choose a different strategy, and both use the same runner auto-detection.

The README describes strategies as one of the two main extension points, alongside new runners. Teams with unusual execution environments can implement a custom strategy.

## Language and Runner Coverage Across 20+ Languages

The README includes a table of supported languages and their runner identifiers. Among the languages listed: C# (.NET: xunit, dotnettest), C++ (CTest, Make), Clojure (Fireplace.vim, Leiningen), Crystal, Dart (Dart Test, Flutter Test), Elixir (ESpec, ExUnit), Elm, Erlang (CommonTest, EUnit, PropEr), Go (Ginkgo, Go, Rich-Go, Delve), Groovy (Maven, Gradle), Haskell (stack, cabal), Java (Maven, Gradle), JavaScript (over 20 runners), Kotlin, Lua (Busted), Mint, Nim, PHP (Behat, Codeception, Kahlan, Peridot, Pest, PHPUnit, Sail, PHPSpec, Dusk), Perl (Prove), Python (Behave, Django, Mamba, Nose, Nose2, PyTest, PyUnit, RobotFramework), and Racket.

The JavaScript coverage is the most extensive, reflecting the diversity of the JavaScript testing ecosystem. Cypress, Playwright, Jest, Mocha, and Vitest are all listed as separate runner identifiers. This breadth is useful for monorepos or full-stack projects where different parts of the codebase use different testing tools.

The runner table in the README is the authoritative reference for checking whether a specific tool is supported before installing vim-test.

## vim-test vs neotest and Maintenance

neotest is the most commonly compared alternative, appearing directly in the related search data for vim-test. neotest is a Neovim-only testing framework written in Lua that uses Neovim's native async API and tree-sitter integration to run tests, display results in a dedicated UI panel, and navigate diagnostics. It is not compatible with Vim (only Neovim).

vim-test by contrast works in both Vim and Neovim, is written in Vim Script, and uses a simpler output model that pipes results to the editor's built-in mechanisms or to a strategy-selected execution environment. There is no visual test results tree built into vim-test. The trade-off is that vim-test is usable on both editors and requires no Lua dependency, while neotest provides richer Neovim-specific features for users who have committed to Neovim.

The last push to the vim-test repository was on 2026-09-16. The repository is not archived, and the CHANGELOG.md tracks feature changes over time. The plugin is MIT-licensed. CONTRIBUTING.md describes how to add a new runner or strategy, which is the mechanism for extending coverage to unsupported tools.

## Conclusion

vim-test is the right choice for Vim and Neovim users who work across multiple languages and want a single, consistent interface for running tests without leaving the editor. The zero-configuration auto-detection and the nearest-test polyfill are practical features that reduce context switching. Engineers who have already moved fully to Neovim and want native Lua integration, async test output, and a visual results tree should evaluate neotest instead. Before adding vim-test to a new project, confirm your test runner is in the supported list by checking the runner identifiers in the README; if it is not, vim-test is extendable and CONTRIBUTING.md describes how to add a runner.

## FAQ

### What is vim-test?

vim-test is a Vim plugin that runs tests from within the editor across more than 20 programming languages. It auto-detects the appropriate test runner from the project context, requires zero configuration, and provides commands for running the nearest test, the current file's tests, or the full test suite.

### Does vim-test work with Neovim?

Yes. vim-test works with both Vim and Neovim. Users who want Neovim-specific features such as async test execution with a visual results panel should also evaluate neotest, which is a Neovim-only alternative written in Lua.

### What do I do if my test runner is not supported by vim-test?

vim-test is designed to be extendable. The CONTRIBUTING.md file in the repository describes how to add a new runner. You can also set a runner identifier manually for projects where auto-detection picks the wrong tool.

## Sources

- [Issues](https://github.com/vim-test/vim-test/issues)
- [License: MIT](https://github.com/vim-test/vim-test/blob/master/LICENSE)
- [README](https://github.com/vim-test/vim-test/blob/master/README.md)
- [vim-test/vim-test on GitHub](https://github.com/vim-test/vim-test)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vim-test-vim-test