{"id":13479806,"url":"https://github.com/vim-test/vim-test","last_synced_at":"2025-12-17T17:20:39.359Z","repository":{"id":24638749,"uuid":"28048077","full_name":"vim-test/vim-test","owner":"vim-test","description":"Run your tests at the speed of thought","archived":false,"fork":false,"pushed_at":"2025-04-02T15:23:23.000Z","size":1943,"stargazers_count":3070,"open_issues_count":117,"forks_count":399,"subscribers_count":21,"default_branch":"master","last_synced_at":"2025-04-28T13:58:41.239Z","etag":null,"topics":["neovim","tdd","test-runner","testing","vim"],"latest_commit_sha":null,"homepage":"","language":"Vim Script","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/vim-test.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2014-12-15T17:34:43.000Z","updated_at":"2025-04-19T15:51:10.000Z","dependencies_parsed_at":"2023-02-19T18:01:40.935Z","dependency_job_id":"46348aca-9076-45b6-8d76-c1ccf2e68a22","html_url":"https://github.com/vim-test/vim-test","commit_stats":{"total_commits":670,"total_committers":244,"mean_commits":"2.7459016393442623","dds":0.6611940298507463,"last_synced_commit":"c090bfd93919888bb0b86e1ab707bc6a3095097f"},"previous_names":[],"tags_count":6,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vim-test%2Fvim-test","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vim-test%2Fvim-test/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vim-test%2Fvim-test/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vim-test%2Fvim-test/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/vim-test","download_url":"https://codeload.github.com/vim-test/vim-test/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254027904,"owners_count":22002133,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["neovim","tdd","test-runner","testing","vim"],"created_at":"2024-07-31T16:02:23.258Z","updated_at":"2025-12-17T17:20:39.309Z","avatar_url":"https://github.com/vim-test.png","language":"Vim Script","readme":"# test.vim\n![CI workflow](https://github.com/vim-test/vim-test/actions/workflows/ci.yml/badge.svg)\n\nA Vim wrapper for running tests on different granularities.\n\n\u003cimg alt=\"usage overview\" src=\"https://github.com/vim-test/vim-test/blob/master/screenshots/granularity.gif\" width=770 height=503\u003e\n\n## Features\n\n* Zero dependencies\n* Zero configuration required (it Does the Right Thing™, see [**Philosophy**](https://github.com/vim-test/vim-test/wiki))\n* Wide range of test runners which are automagically detected\n* **Polyfills** for nearest tests (by [constructing regexes](#commands))\n* Wide range of execution environments (\"[strategies](#strategies)\")\n* Fully customized CLI options configuration\n* Extendable with new runners and strategies\n\nTest.vim consists of a core which provides an abstraction over running any kind\nof tests from the command-line. Concrete test runners are then simply plugged\nin, so they all work in the same unified way. Currently the following test\nrunners are supported:\n\n| Language | Test Runners | Identifiers |\n| -------------: | :----------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- |\n| **C#** | .NET | `xunit`, `dotnettest` |\n| **C++** | CTest,Make | `ctest`, `make` |\n| **Clojure** | Fireplace.vim, Leiningen | `fireplacetest`, `leintest` |\n| **Crystal** | Crystal | `crystalspec` |\n| **Dart** | Dart Test, Flutter Test | `darttest`, `fluttertest`\n| **Elixir** | ESpec, ExUnit | `espec`, `exunit` |\n| **Elm** | elm-test | `elmtest` |\n| **Erlang** | CommonTest, EUnit, PropEr | `commontest`, `eunit`, `proper` |\n| **Go** | Ginkgo, Go, Rich-Go, Delve | `ginkgo`, `gotest`, `richgo`, `delve` |\n| **Groovy** | Maven, Gradle | `maventest`, `gradletest` |\n| **Haskell** | stack, cabal | `stacktest`, `cabaltest` |\n| **Java** | Maven, Gradle (Groovy and Kotlin DSL) | `maventest`, `gradletest` |\n| **JavaScript** | Ava, Cucumber.js, Cypress, Deno, Ember, Intern, Jasmine, Jest, Karma, Lab, Mocha, ng test, NX, Playwright, ReactScripts, TAP, Teenytest, WebdriverIO | `ava`, `cucumberjs`, `cypress`, `deno`, `ember exam`, `intern`, `jasmine`, `jest`, `karma`, `lab`, `mocha`, `ngtest` , `nx`, `playwright`, `reactscripts`, `tap`, `teenytest`, `webdriverio`, `vue-test-utils`, `vitest`|\n| **Kotlin** | Gradle (Groovy and Kotlin DSL) | `gradletest` |\n| **Lua** | Busted | `busted` |\n| **Mint** | Mint | `minttest` |\n| **Nim** | Nim | `unittest` |\n| **PHP** | Behat, Codeception, Kahlan, Peridot, Pest, PHPUnit, Sail, PHPSpec, Dusk | `behat`, `codeception`, `dusk`, `kahlan`, `peridot`, `phpunit`, `sail`, `phpspec`, `pest` |\n| **Perl** | Prove | `prove` |\n| **Python** | Behave, Django, Mamba, Nose, Nose2, PyTest, PyUnit | `behave`, `djangotest`, `djangonose`, `mamba`, `nose`, `nose2`, `pytest`, `pyunit` |\n| **Racket** | RackUnit | `rackunit` |\n| **Ruby** | Cucumber, [M], [Minitest][minitest], Rails, RSpec, TestBench | `cucumber`, `m`, `minitest`, `rails`, `rspec`, `testbench` |\n| **Rust** | Cargo, cargo-nextest | `cargotest`, `cargonextest` |\n| **Scala** | SBT, Bloop | `sbttest`, `blooptest` |\n| **Shell** | Bats, ShellSpec | `bats`, `shellspec` |\n| **Swift** | Swift Package Manager | `swiftpm` |\n| **VimScript** | Vader.vim, Vroom, VSpec, Themis, Testify | `vader`, `vroom`, `vspec`, `themis`, `testify` |\n| **Zig** | ZigTest | `zigtest` |\n| **Gleam** | GleamTest | `gleamtest` |\n\n\n## Setup\n\nUsing [vim-plug](https://github.com/junegunn/vim-plug), add\n```vim\nPlug 'vim-test/vim-test'\n```\nto your `.vimrc` file (see vim-plug documentation for where), and run `:PlugInstall`.\n\nAdd your preferred mappings to your `.vimrc` file:\n\n```vim\nnmap \u003csilent\u003e \u003cleader\u003et :TestNearest\u003cCR\u003e\nnmap \u003csilent\u003e \u003cleader\u003eT :TestFile\u003cCR\u003e\nnmap \u003csilent\u003e \u003cleader\u003ea :TestSuite\u003cCR\u003e\nnmap \u003csilent\u003e \u003cleader\u003el :TestLast\u003cCR\u003e\nnmap \u003csilent\u003e \u003cleader\u003eg :TestVisit\u003cCR\u003e\n```\n\n| Command | Description |\n| :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `:TestNearest` | In a test file runs the test nearest to the cursor, otherwise runs the last nearest test. In test frameworks that don't support line numbers it will **polyfill** this functionality with [regexes](#commands). |\n| `:TestClass` | In a test file runs the first test class found on the same line as or above the cursor. (Currently only supported by Pytest) |\n| `:TestFile` | In a test file runs all tests in the current file, otherwise runs the last file tests. |\n| `:TestSuite` | Runs the whole test suite (if the current file is a test file, runs that framework's test suite, otherwise determines the test framework from the last run test). |\n| `:TestLast` | Runs the last test. |\n| `:TestVisit` | Visits the test file from which you last run your tests (useful when you're trying to make a test pass, and you dive deep into application code and close your test buffer to make more space, and once you've made it pass you want to go back to the test file to write more tests). |\n\n## Strategies\n\nTest.vim can run tests using different execution environments called\n\"strategies\". To use a specific strategy, assign it to a variable:\n\n```vim\n\" make test commands execute using dispatch.vim\nlet test#strategy = \"dispatch\"\n```\n\n| Strategy | Identifier | Description |\n| :-----: | :-----: | :---------- |\n| **Basic**\u0026nbsp;(default) | `basic` | Runs test commands with `:!` on Vim, and with `:terminal` on Neovim. |\n| **Make** | `make` `make_bang` | Runs test commands with `:make` or `:make!`. |\n| **Neovim** | `neovim` | Runs test commands with `:terminal` in a split window. |\n| **Neovim sticky** | `neovim_sticky` | Runs test commands with `:terminal` in a split window, but keeps it open for subsequent runs. |\n| **Neovim VS Code** | `neovim_vscode` | Runs test commands in with VS Code terminal, keeps the focus to EditorGroup.\n| **Vim8 Terminal** | `vimterminal` | Runs test commands with `term_start()` in a split window. |\n| **[Dispatch]** | `dispatch` `dispatch_background` | Runs test commands with `:Dispatch` or `:Dispatch!`. |\n| **[Spawn]** | `spawn` `spawn_background` | Runs test commands using dispatch.vim `:Spawn` or `:Spawn!`. |\n| **[Vimux]** | `vimux` | Runs test commands in a small tmux pane at the bottom of your terminal. |\n| **[Tslime]** | `tslime` | Runs test commands in a tmux pane you specify. |\n| **[Slimux]** | `slimux` | Runs test commands in a tmux pane you specify. |\n| **[Neoterm]** | `neoterm` | Runs test commands with `:T`, see neoterm docs for display customization. |\n| **[Toggleterm]** | `toggleterm` | Runs test commands with `TermExec` |\n| **[Floaterm]** | `floaterm` | Runs test commands within floating/popup terminal, see [floaterm docs](https://github.com/voldikss/vim-floaterm/blob/master/README.md) for display customization. |\n| **[Neomake]** | `neomake` | Runs test commands asynchronously with `:NeomakeProject`. |\n| **[MakeGreen]** | `makegreen` | Runs test commands with `:MakeGreen`. |\n| **[VimShell]** | `vimshell` | Runs test commands in a shell written in VimScript. |\n| **[Vim\u0026nbsp;Tmux\u0026nbsp;Runner]** | `vtr` | Runs test commands in a small tmux pane. |\n| **[Tmuxify]** | `tmuxify` | Runs test commands in a small tmux pane at the bottom of your terminal. |\n| **[VimProc]** | `vimproc` | Runs test commands asynchronously. |\n| **[AsyncRun]** | `asyncrun` `asyncrun_background` `asyncrun_background_term` | Runs test commands asynchronosuly using new APIs in Vim 8 and NeoVim (`:AsyncRun`, `:AsyncRun -mode=async -silent`, or `:AsyncRun -mode=term -pos=tab -focus=0 -listed=0`). |\n| **Terminal.app** | `terminal` | Sends test commands to Terminal (useful in MacVim GUI). |\n| **iTerm2.app** | `iterm` | Sends test commands to iTerm2 \u003e= 2.9 (useful in MacVim GUI). |\n| **[Kitty]** | `kitty` | Sends test commands to Kitty terminal. |\n| **[Shtuff]** | `shtuff` | Sends test commands to remote terminal via [shtuff][Shtuff]. |\n| **[Harpoon]** | `harpoon` | Sends test commands to neovim terminal using a terminal managed by [harpoon][Harpoon]. By default commands are sent to terminal number 1, you can choose your terminal by setting `g:test#harpoon_term` with the terminal you want |\n| **[WezTerm]** | `wezterm` | Sends test commands to an adjacent [WezTerm][WezTerm] pane. |\n\nYou can also set up strategies per granularity:\n\n```vim\nlet test#strategy = {\n \\ 'nearest': 'neovim',\n \\ 'file': 'dispatch',\n \\ 'suite': 'basic',\n\\}\n```\n\nor even per command:\n\n```\n:TestFile -strategy=neovim\n```\n\nSome strategies clear the screen before executing the test command, but you can\ndisable this:\n\n```vim\nlet g:test#preserve_screen = 1\n```\n\nThe Vimux strategy will not clear the screen by default, but you can enable it\nby explicitly setting `test#preserve_screen` to `0`.\n\nOn Neovim the \"basic\" and \"neovim\" strategies will run test commands using\nNeovim's terminal, and leave you in insert mode, so that you can just press\n\"Enter\" to close the terminal session and go back to editing. If you want to\nscroll through the test command output, you'll have to first switch to normal\nmode. The built-in mapping for exiting terminal insert mode is `CTRL-\\ CTRL-n`,\nwhich is difficult to press, so I recommend mapping it to `CTRL-o`:\n\n```vim\nif has('nvim')\n tmap \u003cC-o\u003e \u003cC-\\\u003e\u003cC-n\u003e\nendif\n```\n\nIf you prefer, you can instead have the terminal open in normal mode, so it does\nnot close on key press.\n\n```vim\nlet g:test#neovim#start_normal = 1 \" If using neovim strategy\nlet g:test#basic#start_normal = 1 \" If using basic strategy\n```\n\nBy default vim-test will echo the test command before running it. You can\ndisable this behavior with:\n\n```vim\nlet g:test#echo_command = 0\n```\n\nWith the Neovim sticky strategy, if an additional test run is requested before\nthe previous one has finished, it will either wait or fail to run at all.\nYou can customize this behavior with the following options:\n\n```vim\nlet g:test#preserve_screen = 0 \" Clear screen from previous run\nlet g:test#neovim_sticky#kill_previous = 1 \" Try to abort previous run\nlet g:test#neovim_sticky#reopen_window = 1 \" Reopen terminal split if not visible\nlet g:test#neovim_sticky#use_existing = 1 \" Use manually opened terminal, if exists\n```\n\n### Kitty strategy setup\n\nBefore you can run tests in a kitty terminal window using the kitty strategy,\nplease make sure:\n\n- you start kitty setting up remote control and specifying a socket for kitty\n to listen to, like this:\n\n ```\n $ kitty -o allow_remote_control=yes --listen-on unix:/tmp/mykitty\n ```\n\n or via `kitty.conf`:\n\n ```\n allow_remote_control yes\n listen_on unix:/tmp/mykitty\n ```\n\n- you export an environment variable `$KITTY_LISTEN_ON` with the same socket, like:\n\n ```\n $ export KITTY_LISTEN_ON=unix:/tmp/mykitty\n ```\n\n or if via `kitty.conf` (it appends kitty's PID):\n\n ```\n $ export KITTY_LISTEN_ON=unix:/tmp/mykitty-$PPID\n ```\n\n\n### Shtuff strategy setup\n\nThis strategy lets you run commands in a remote terminal without needing tools\nlike `tmux` or special terminals such as Kitty.\n\nBefore you can run tests using this strategy, you will need to have a terminal\nsetup as a receiver, and also you'll need to set `g:shtuff_receiver` in your\nvimrc file.\n\nIn your terminal of choice:\n\n```\n$ shtuff as devrunner\n```\n\nAnd in your vimrc:\n\n```\nlet g:shtuff_receiver = 'devrunner'\n```\n\n### `asyncrun_background` and `asyncrun_background_term` setup\n\n`asyncrun_background` will load test results into the quickfix buffer.\n\n`asyncrun_background_term` will open a terminal in a new tab and run the tests while\nremaining in the current window.\n\nThese are hardcoded solutions and will not be affected by your global `AsyncRun` settings.\nIf you want to switch between them then change `test#strategy`.\n\nNote: the base `asyncrun` option will be affected by your global asyncrun settings.\n\n### Quickfix Strategies\n\nIf you want your test results to appear in the quickfix window, use one of the\nfollowing strategies:\n\n * Make\n * Neomake\n * MakeGreen\n * Dispatch.vim\n * `asyncrun_background`\n\nRegardless of which you pick, it's recommended you have Dispatch.vim installed as the\nstrategies will automatically use it to determine the correct compiler, ensuring the\ntest output is correctly parsed for the quickfix window.\n\nAs Dispatch.vim just determines the compiler, you need to make sure the Vim distribution\nor a plugin has a corresponding compiler for your test runner, or you may need to write a\ncompiler plugin.\n\nIf the test command prefix doesn't match the compiler's `makeprg` then use the\n`g:dispatch_compiler` variable. For example if your test command was `./vendor/bin/phpunit`\nbut you wanted to use the phpunit2 compiler:\n\n```vim\nlet g:dispatch_compilers = {}\nlet g:dispatch_compilers['./vendor/bin/'] = ''\nlet g:dispatch_compilers['phpunit'] = 'phpunit2'\n```\n\n### Custom Strategies\n\nStrategy is a function which takes one argument – the shell command for the\ntest being run – and it is expected to run that command in some way. Test.vim\ncomes with many predefined strategies (see above), but if none of them suit\nyour needs, you can define your own custom strategy:\n\n```vim\nfunction! EchoStrategy(cmd)\n echo 'It works! Command for running tests: ' . a:cmd\nendfunction\n\nlet g:test#custom_strategies = {'echo': function('EchoStrategy')}\nlet g:test#strategy = 'echo'\n```\n\n## Transformations\n\nYou can automatically apply transformations of your test commands by\nregistering a \"transformation\" function. The following example demonstrates how\nyou could set up a transformation for Vagrant:\n\n```vim\nfunction! VagrantTransform(cmd) abort\n let vagrant_project = get(matchlist(s:cat('Vagrantfile'), '\\vconfig\\.vm.synced_folder [\"''].+[''\"], [\"''](.+)[''\"]'), 1)\n return 'vagrant ssh --command '.shellescape('cd '.vagrant_project.'; '.a:cmd)\nendfunction\n\nlet g:test#custom_transformations = {'vagrant': function('VagrantTransform')}\nlet g:test#transformation = 'vagrant'\n```\n\n## Commands\n\n\u003cimg alt=\"nearest polyfill\" src=\"https://github.com/vim-test/vim-test/blob/master/screenshots/nearest.gif\" width=770 height=323\u003e\n\nYou can execute test.vim commands directly, and pass them CLI options:\n\n```\n:TestNearest --verbose\n:TestFile --format documentation\n:TestSuite --fail-fast\n:TestLast --backtrace\n```\n\nIf you want some options to stick around, see [Configuring](#configuring).\n\n### Environment variables\n\nEnvironment variables are automatically detected from the arguments based on\n`\u003cVARIABLE\u003e=value` format, and prepended to the test command:\n\n```vim\nTestFile COVERAGE=1\n\" COVERAGE=1 bundle exec rspec something_spec.rb\n```\n\n### Runner commands\n\nAside from the main commands, you get a corresponding Vim command for each\ntest runner (which also accept options):\n\n```\n:RSpec --tag ~slow\n:Mocha --grep 'API'\n:ExUnit --trace\n:Nose --failed\n```\n\nThese commands are useful when using multiple testing frameworks in the same\nproject, or as a wrapper around your executable. To avoid pollution they are\nnot defined by default, instead you can choose the ones you want:\n\n```vim\nlet g:test#runner_commands = ['Minitest', 'Mocha']\n```\n\n## Configuring\n\n### CLI options\n\nIf you want some CLI options to stick around, you can configure them in your\n`.vimrc`:\n\n```vim\nlet test#ruby#minitest#options = '--verbose'\nlet test#javascript#denotest#options = '--quiet'\n```\n\nYou can also choose a more granular approach:\n\n```vim\nlet test#ruby#rspec#options = {\n \\ 'nearest': '--backtrace',\n \\ 'file': '--format documentation',\n \\ 'suite': '--tag ~slow',\n\\}\n```\n\nYou can also specify a global approach along with the granular options for the\nspecified test runner:\n\n```vim\nlet test#ruby#rspec#options = {\n \\ 'all': '--backtrace',\n \\ 'suite': '--tag ~slow',\n\\}\n```\n\nThe cargotest runner lets you specify the test-options argument as follows:\n\n```vim\nlet test#rust#cargotest#test_options = '-- --nocapture'\n```\n\nOr using a more granular approach:\n\n```vim\nlet test#rust#cargotest#test_options = {\n \\ 'nearest': ['--', '--nocapture'],\n \\ 'file': '',\n\\}\n```\n\nThe gotest runner let you specify the -args argument as follows:\n```vim\nlet test#go#gotest#args = 'a=b'\n```\n\n### Vim8 / Neovim terminal position\n\nBoth the `neovim` and `Vim8 Terminal` strategy will open a split window on the\nbottom by default, but you can configure a different position or orientation.\nWhatever you put here is passed to `new` - so, you may also specify size (see\n`:help opening-window` or `:help new` for more info):\n\n```vim\n\" for neovim\nlet test#neovim#term_position = \"topleft\"\nlet test#neovim#term_position = \"vert\"\nlet test#neovim#term_position = \"vert botright 30\"\n\" or for Vim8\nlet test#vim#term_position = \"belowright\"\n```\n\nFor full list of variants, see `:help opening-window`.\n\n### Executable\n\nYou can instruct test.vim to use a custom executable for a test runner.\n\n```vim\nlet test#ruby#rspec#executable = 'foreman run rspec'\n```\n\n### File pattern\n\nTest.vim has file pattern it uses to determine whether a file belongs to\ncertain testing framework. You can override that pattern by overriding the\n`file_pattern` variable:\n\n```vim\nlet test#ruby#minitest#file_pattern = '_spec\\.rb' \" the default is '\\v(((^|/)test_.+)|_test)(spec)@\u003c!\\.rb$'\n```\n\n### Filename modifier\n\nBy default test.vim generates file paths relative to the working directory. If\nyou're using a strategy which sends commands to a shell which is `cd`-ed into\nanother directory, you might want to change the filename modifier to generate\nabsolute paths:\n\n```vim\nlet test#filename_modifier = ':.' \" test/models/user_test.rb (default)\nlet test#filename_modifier = ':p' \" /User/janko/Code/my_project/test/models/user_test.rb\nlet test#filename_modifier = ':~' \" ~/Code/my_project/test/models/user_test.rb\n```\n\n### Working directory\n\nTest.vim relies on you being `cd`-ed into the project root. However, sometimes\nyou may want to execute tests from a different directory than Vim's current\nworking directory. You might have a bigger project or monorepo with many subprojects,\nor you might be using [`autochdir`]. In any case, you can tell test.vim to use a\ndifferent working directory for running tests:\n\n```vim\nlet test#project_root = \"/path/to/your/project\"\n```\n\nAlternatively you can pass in a function that'll be evaluated before each test run.\n```vim\nfunction! CustomPath()\n return \"~/Project\"\nendfunction\n\nlet test#project_root = function('CustomPath')\n```\n\n### Language-specific\n\n#### Python\n\nIf your project has a [pytest configuration file](https://docs.pytest.org/en/7.1.x/reference/customize.html),\nthen pytest will automatically be detected. For other Python test runners, test.vim\nhas no way of detecting which one did you intend to use. By default, the first\navailable will be chosen, but you can force a specific one:\n\n``` vim\nlet test#python#runner = 'pytest'\n\" Runners available are 'pytest', 'nose', 'nose2', 'djangotest', 'djangonose', 'mamba', and Python's built-in unittest as 'pyunit'\n```\n\nThe `pytest` and `djangotest` runner optionally supports [pipenv](https://github.com/pypa/pipenv).\nIf you have a `Pipfile`, it will use `pipenv run pytest` instead of just\n`python -m pytest`. They also support [poetry](https://github.com/sdispater/poetry)\nand will use `poetry run pytest` if it detects a `poetry.lock`. The pyunit and nose\nrunner supports [pipenv](https://github.com/pypa/pipenv) as well and will\nrespectively use `pipenv run python -m unittest` or `pipenv run python -m nosetests`\nif there is a `Pipfile`. It also supports [pdm](https://pdm.fming.dev/) as well and\nwill use `poetry run pytest` if there is a `pdm.lock` file.\n\n#### Java\n\nFor the same reason as Python, runner detection works the same for Java. To\nforce a specific runner:\n\n``` vim\nlet test#java#runner = 'gradletest'\n```\n\nThere is a specific strategy for Java with maven which invokes the mvn verify for a file instead of mvn test tailored for integration tests. In this way you can leverage the pre-integration goals, like firing up a database and so on. This strategy is called 'integration' and you can setup a command for it (preferably within the Java filetype plugin):\n\n``` vim\ncommand! -nargs=* -bar IntegrationTest call test#run('integration', split(\u003cq-args\u003e))\n```\n\nWith this set up you can run your integration tests with the :IntegrationTest plugin for that single file and module. As there might be some dependencies between the maven modules you might need to pass in other parameters for the tests just like any other commands in vim-test. Here is a mapping with other optional parameters:\n\n\n``` vim\nnnoremap \u003csilent\u003e\u003cleader\u003eitf :IntegrationTest -Dtest=foo -DfailIfNoTests=false -am -Dpmd.skip=true -Dcheckstyle.skip=true\u003cCR\u003e\n```\n\nIf you want to customize the Maven test command, you can set `g:test#java#maventest#test_cmd` in your vimrc file.\n\n```vim\n let g:test#java#maventest#test_cmd = 'surefire:test -Dtest'\n```\n\nThe above command makes sure that no surefire tests will be run (by passing in a dummy test and makes sure that the plugin won't fail), it also makes the dependent modules, skips PMD and checkstyle checks as well.\n\nOnly for maven, the commands `:TestFile` and `:TestNearest` use the same strategy and you can use them to run the integration tests from file or method.\n\nThey use `mvn verify` if the filename ends with *IT, *ITCase or *Integration. The most common plugins are skipped in this strategy to improve the test time.\n\n* Sonar\n* PIT\n* Jacoco\n* Checkstyle\n* PMD\n* DependencyCheck\n\n```sh\nmvn verify -Dsonar.skip=true -Dpit.report.skip=true -Dpit.skip=true -Dpmd.skip=true -Dcheckstyle.skip=true -Ddependency-check.skip=true -Djacoco.skip=true -Dfailsafe.only=true\n```\n\nAlso, the parameter `-Dfailsafe.only` is added to the command by vim-test, so you can use it to configure other things in the pom.xml, for example to avoid surefire tests:\n\n```xml\n \u003cplugin\u003e\n \u003cgroupId\u003eorg.apache.maven.plugins\u003c/groupId\u003e\n \u003cartifactId\u003emaven-surefire-plugin\u003c/artifactId\u003e\n \u003cversion\u003e${surefire.version}\u003c/version\u003e\n \u003cconfiguration\u003e\n \u003cskipTests\u003e${failsafe.only}\u003c/skipTests\u003e\n ....\n \u003c/configuration\u003e\n ...\n \u003c/plugin\u003e\n```\n\nAnd keep the parameter `-DskipTests` working as expected:\n\n```xml\n \u003cproperties\u003e\n \u003cfailsafe.only\u003e${skipTests}\u003c/failsafe.only\u003e\n \u003c/properties\u003e\n```\n\n#### Scala\n\nFor the same reason as Python, runner detection works the same for Scala. To\nforce a specific runner:\n\n``` vim\nlet test#scala#runner = 'blooptest'\n```\n\nYou may have subprojects inside your main sbt projects. Bloop project detection\nuses your main project to run tests. If you need to run test inside your subproject,\nyou can specify custom projects with:\n\n```vim\nlet g:test#scala#blooptest#project_name = 'custom-project'\n```\n\nWith this configuration, the test runner will run test for `custom-project`:\n\n```sh\n$ bloop test custom-project\n```\n\n#### Go\n\nFor the same reason as Python, runner detection works the same for Go. To\nforce a specific runner:\n\n``` vim\nlet test#go#runner = 'ginkgo'\n\" Runners available are 'gotest', 'ginkgo', 'richgo', 'delve'\n```\n\nYou can also configure the `delve` runner with a different key mapping\nalongside another:\n\n```vim\nnmap \u003csilent\u003e t\u003cC-n\u003e :TestNearest\u003cCR\u003e\nfunction! DebugNearest()\n let g:test#go#runner = 'delve'\n TestNearest\n unlet g:test#go#runner\nendfunction\nnmap \u003csilent\u003e t\u003cC-d\u003e :call DebugNearest()\u003cCR\u003e\n```\n\nIf `delve` is selected and [vim-delve](https://github.com/sebdah/vim-delve) is\nin use, breakpoints and tracepoints that have been marked with vim-delve will\nbe included.\n\n#### Ruby\n\nUnless binstubs are detected (e.g. `bin/rspec`), test commands will\nautomatically be prepended with `bundle exec` if a Gemfile is detected, but you\ncan turn it off:\n\n```vim\nlet test#ruby#bundle_exec = 0\n```\n\nIf binstubs are detected, but you don't want to use them, you can turn them off:\n\n```vim\nlet test#ruby#use_binstubs = 0\n```\n\nIf your binstubs are not instrumented with spring, you can turn on using the `spring` bin (`bin/spring`) directly using:\n\n```vim\nlet test#ruby#use_spring_binstub = 1\n```\n\n#### JavaScript\n\nTest runner detection for JavaScript works by checking which runner is listed in the package.json dependencies. If you have globally installed the runner make sure it's also listed in the dependencies. When you have multiple runners listed in the package.json dependencies you can specify a runner like so:\n\n```vim\nlet g:test#javascript#runner = 'jest'\n```\n\n#### Haskell\n\nThe `stacktest` runner is used by default. You can switch to `cabaltest` like so:\n\n```vim\nlet g:test#haskell#runner = 'cabaltest'\n```\n\nYou can pass additional arguments to the test runner by setting its `test_command`. Here's an example for cabal:\n\n```vim\nlet g:test#haskell#cabaltest#test_command = 'test --test-show-details=direct'\n```\n\nThe runners currently supports running tests with the [HSpec](http://hackage.haskell.org/package/hspec) framework.\n\n\n#### PHP\n\nThe PHPUnit runner has support for the alternate runner [ParaTest](https://github.com/paratestphp/paratest) and will automatically use it if present in `./vendor/bin`. If you prefer to use PHPUnit then override the executable:\n\n```vim\nlet test#php#phpunit#executable = 'phpunit'\n```\n\nSimilarly if you'd prefer to use an alternate runner such as the [Laravel artisan runner](https://laravel.com/docs/7.x/testing) then override the executable:\n\n```vim\nlet test#php#phpunit#executable = 'php artisan test'\n```\n\n#### C++\nPattern for Test File: We assume all your test files are prefixed with \"test_\" or \"Test\". If not, override the following:\n```\n\"Default\nlet g:test#cpp#catch2#file_pattern = '\\v[tT]est.*(\\.cpp)$'\n```\nFile and Individual Test Case: We assume you are using make to compile your executables, whose names are exactly the same as the test file w/o the extension. If you would like to use change the make command, override the following:\n```\nlet g:test#cpp#catch2#make_command = \"make\"\n```\nCreating Test Executables: We assume that a Makefile is located in a \"build\" directory directly below the project root. If not, override the following:\n```\n\" If Makefile is at top of the project root, do this instead\nlet g:test#cpp#catch2#relToProject_build_dir = \".\"\n```\nWe assume that your compiled executables are stored in `build` directory. If not, you can override this with:\n```vim\nlet g:test#cpp#catch2#bin_dir = \"../path/to/your/binaries/dir\"\n```\nSuite: We assume that you are using Cmake as your build system, and are registering each test file to it. If not, override the following command.\n```vim\nlet g:test#cpp#catch2#suite_command = \"ctest --output-on-failure\"\n```\n\n#### Rust\nIf the `nextest` cargo subcommand is available, cargo-nextest is used. `cargo test` is used otherwise. To force a specific runner:\n```vim\nlet g:test#rust#runner = 'cargotest'\n```\n\nIn workspaces, reads the [package name field] from `Cargo.toml`.\n\n[package name field]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field\n\n## Autocommands\n\nIn addition to running tests manually, you can also configure autocommands\nwhich run tests automatically when files are saved.\n\nThe following setup will automatically run tests when a test file or its\nalternate application file is saved:\n\n```vim\naugroup test\n autocmd!\n autocmd BufWrite * if test#exists() |\n \\ TestFile |\n \\ endif\naugroup END\n```\n\n## Projectionist integration\n\nIf [projectionist.vim] is present, you can run a test command from an\napplication file, and test.vim will automatically try to run the\ncommand on the \"alternate\" test file.\n\nYou can disable this integration by doing\n```vim\nlet g:test#no_alternate = 1\n```\n\n### Custom alternate file\n\nIf you are using a different library for jumping between implementation and test file\nyou can define a custom function that returns the test filename.\n\n```vim\nfunction! CustomAlternateFile(cmd)\n return \"test_file_spec.rb\"\nendfunction\n\nlet g:test#custom_alternate_file = function('CustomAlternateFile')\n```\n\n## Overriding test commands\n\nThis is considered an advanced feature, subject to active development and further changes. It overrides the zero configuration approach, and requires you to manually configure the test runners.\n\nTo provide middle ground between well-known test runners working out of the box,\nand per-user configuration, test command can also be specifying by adding a `.vimtest.json`\nfile:\n\n```json\n{\n \"command\": \"echo 'Hello vim-test!'\"\n}\n```\n\nThis will override the command run by all of `:TestNearest`,\n`:TestClass`, `:TestFile` and `:TestSuite` in all files in the `.vimtest.json`'s directory\nand subdirectories, recursively. As such, it can be used to quickly bridge the gap\nfor non-standard projects and share it with other developers.\n\n## Extending\n\nIf you wish to extend this plugin with your own test runners, first of all,\nif the runner is well-known, I would encourage to help me merge it into\ntest.vim.\n\nThat being said, if you want to do this for yourself, you need to do 2 things.\nFirst, add your runner to the list in your `.vimrc`:\n\n```vim\n\" First letter of runner's name must be uppercase\nlet test#custom_runners = {'MyLanguage': ['MyRunner']}\n```\n\nSecond, create `~/.vim/autoload/test/mylanguage/myrunner.vim`, and define the following\nmethods:\n\n```vim\n\" Returns true if the given file belongs to your test runner\nfunction! test#mylanguage#myrunner#test_file(file)\n\n\" Returns test runner's arguments which will run the current file and/or line\nfunction! test#mylanguage#myrunner#build_position(type, position)\n\n\" Returns processed args (if you need to do any processing)\nfunction! test#mylanguage#myrunner#build_args(args)\n\n\" Returns the executable of your test runner\nfunction! test#mylanguage#myrunner#executable()\n```\n\nSee [`autoload/test`](/autoload/test) for examples.\n\n## Choosing which runners to load\n\nAll runners are loaded by default. To select which runners to load, set this\noption:\n\n```vim\nlet test#enabled_runners = [\"mylanguage#myrunner\", \"ruby#rspec\"]\n```\n\nAll other runners will not be loaded.\n\nNote that for your own custom runners, you still need to set `test#custom_runners`.\n\n## Running tests\n\nTests are run using a Ruby test runner, so you'll have to have Ruby installed.\nThen run\n\n```sh\n$ gem install vim-flavor\n```\n\nNow you can run tests with\n\n```sh\n$ vim-flavor test spec/\n```\n\nOr if you're inside of Vim, you can simply run `:VSpec` provided by test.vim.\n\n## Unsaved changes\n\nIf `autowrite` or `autowriteall` are set then unsaved changes will be\nwritten to disk with `:wall` before each test execution.\n\n### Prompt for unsaved changes\n\nYou can enable a user prompt asking whether to write unsaved changes\nprior to executing a test by\n\n```vim\n let g:test#prompt_for_unsaved_changes = 1\n```\n\n## Credits\n\nThis plugin was strongly influenced by Gary Bernhardt's Destroy All Software.\nI also want to thank [rspec.vim], from which I borrowed GUI support for OS X,\nand Windows support. And also thanks to [vroom.vim].\n\n## License\n\nThe gem is available as open source under the terms of the [MIT License](https://opensource.org/license/MIT).\n\n[minitest]: https://github.com/vim-test/vim-test/wiki/Minitest\n[Neoterm]: https://github.com/kassio/neoterm\n[Floaterm]: https://github.com/voldikss/vim-floaterm\n[Neomake]: https://github.com/neomake/neomake\n[Dispatch]: https://github.com/tpope/vim-dispatch\n[Vimux]: https://github.com/benmills/vimux\n[Tslime]: https://github.com/jgdavey/tslime.vim\n[Slimux]: https://github.com/esamattis/slimux\n[Vim\u0026nbsp;Tmux\u0026nbsp;Runner]: https://github.com/christoomey/vim-tmux-runner\n[Tmuxify]: https://github.com/jebaum/vim-tmuxify\n[VimShell]: https://github.com/Shougo/vimshell.vim\n[VimProc]: https://github.com/Shougo/vimproc.vim\n[`autochdir`]: http://vimdoc.sourceforge.net/htmldoc/options.html#'autochdir'\n[rspec.vim]: https://github.com/thoughtbot/vim-rspec\n[vroom.vim]: https://github.com/skalnik/vim-vroom\n[AsyncRun]: https://github.com/skywind3000/asyncrun.vim\n[MakeGreen]: https://github.com/reinh/vim-makegreen\n[M]: http://github.com/qrush/m\n[projectionist.vim]: https://github.com/tpope/vim-projectionist\n[Kitty]: https://github.com/kovidgoyal/kitty\n[Shtuff]: https://github.com/jfly/shtuff\n[Harpoon]: https://github.com/ThePrimeagen/harpoon\n[Ember.js]: https://github.com/emberjs/ember.js\n[Toggleterm]: https://github.com/akinsho/toggleterm.nvim\n[WezTerm]: https://github.com/wez/wezterm\n","funding_links":[],"categories":["Vim Script","Tools","编辑器"],"sub_categories":["Task Running","资源传输下载"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvim-test%2Fvim-test","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvim-test%2Fvim-test","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvim-test%2Fvim-test/lists"}