Runs your UnitTests with py.test displaying red/green bars and errors
follow @alfredodeza for updates
A simple way of running your tests (with py.test) from within VIM.
Talking with Holger Krekel (original author of py.test and vim user) we thought it would be neat to be able to call it from vim and get some immediate results.
This is especially useful when you are tweaking and do not want to be moving around between the terminal and your vim session.
.. image:: https://github.com/alfredodeza/pytest.vim/raw/master/extras/session.png
.. image:: https://github.com/alfredodeza/pytest.vim/raw/master/extras/fails.png
This plugin is a file type plugin, which means that it is only enabled when the matching file type (Python in this case) is being edited. To ensure the plugin works correctly, the following setting must be enabled (usually in
Without any install frameworks, all is needed is to drop the
pytest.vimfile in one of the Vim runtime paths, in the subdirectory
vim-pathogenthe whole repository can be placed in
.vim/bundle. Otherwise please follow the guidelines of the package manager of choice.
This plugin provides a single command::
All arguments are able to be tab-completed. To ensure the plugin will be loaded, these settings must be enabled::
:set filetype on :set filetype plugin on
For running tests the plugin provides 4 arguments with an optional one. These arguments are::
class method function file project
As you may expect, those will focus on the tests for the current class, method, function, the file or project.
If you are in a class and want to run all the tests for that class, you would call this plugin like::
Whenever a command is triggered a small message displays informing you that the plugin is running a certain action. In the above call, you would see something like this::
Running tests for class TestMyClass
If you would like to see the complete py.test output you can add an optional
verboseflag to any of the commands for Pytest. For the previous command, it would look like::
:Pytest class verbose
This would open a split scratch buffer that you can fully interact with. You can close this buffer with ':wq' or you can hit 'q' at any moment in that buffer to close it.
When tests are successful a green bar appears. If you have any number of fails you get a red bar with a line-by-line list of line numbers and errors.
I strongly encourage a mapping for the above actions. For example, if you wanted leader (the leader key is '\' by default) mappings you would probably do them like this::
" Pytest nmap f :Pytest file nmap c :Pytest class nmap m :Pytest method
If you are working on a project, this plugin provides a way to run tests from anywhere within the project tree like this::
" Tests are in /path/to/project/tests/ " Working on /path/to/project/module/file.py :Pytest project
This would run all of the project tests (in /path/to/project/tests/) related to the active project. This works with a directory called "tests" or a file called "tests.py". It should be noted that this plugin searches upward through the directory tree, taking the first entry it finds. For example::
" Working on /home/project/file.py /home/tests/ " This set of tests will not be run /home/project/tests/ " This set of tests will be run
It is easy to check which set of tests will be run (the project test working directory)::
This plugin also provides a way to jump to the actual error. Since errors can be living in a file other than your test (e.g. a syntax error in your source that triggers an assertion errro in the current file) you can also jump to that file. The list of jumping-to-error arguments are::
first last next previous end
Pytest DOES NOT JUMP AUTOMATICALLY to errors. You have to call the action. When you call a jump, a split buffer is opened with a file (if it is not the same as the one you are currently editing) and places you in the same line number were the error was reported.
If an error starts in the current file but ends on a different one, you can call that
end of errorby calling
Finally, you can also display in a split scratch buffer either the last list of failed tests (with line numbers, errors and paths) or the last
py.testsession (similar to what you would see in a terminal). The arguments that you would need to provide for such actions are::
sessionis the buffer with a similar output to the terminal (but with syntax highlighting) and
failshas the list of last fails with the exceptions.
If you are looking for the actual error, we have stripped it from the normal reporting but you can call it at any time with::
The reason behind this is that as soon as you hit any key, the quick display goes away. With a split buffer you are in control and you can quit that window when you decide - while you work on fixing errors.
The commands that open the last session and the last fails are toggable: they will close the scratch buffer if it is open or will open it if its closed.
If you have ever needed to get into a
pdbsession and debug your code, you already know that it is a horrible experience to be jumping between Vim and the terminal. pytest.vim now includes a way of calling it with 2 options that will let you drop to a shell (inside Vim!) and control your pdb session.
py.test pdb on fail
Use this option when you need to use the built-in pdb support from py.test (e.g. drop to pdb when a test fails).
:Pytest class --pdb
The above command shows
classbut you can use this with all the objects supported (
py.test no capture
If you are placing
import pdb; pdb.set_trace()somewhere in your code and you want to drop to pdb when that code gets executed, then you need to pass in the no-capture flag::
:Pytest class -s
Again the above command shows
classbut you can use this with all the objects supported (
This plugin provides a way to have a better shell experience when running
pdbflags by using native Vim (only available with Vim 8 and newer).
This is an extra option that will allow you to loop (run again) on fail. If the test fails, then this option will make Vim run the same test again as soon as the file is written.
Once the test passes, it will no longer re-run the tests again. This option is available for
file. You would call it like::
:Pytest method looponfail
If for some reason you need to reset and clear all global variables that affect the plugin you can do so by running the following command::
This is specifically useful when
looponfailhas been enabled and you want to stop its automatic behavior. Remember that
looponfailwill run every time you write the buffer and will keep doing so unless your test passes.
Now when the Failed Error list is open and it as focus (cursor is currently in that window) you can move to the next or previous failed test line by using the arrow keys,
Whenever you hit the bottom or the top of the list, you can loop around it!
If you hit an error that displays not the previous window (e.g. your test file) then a message will state that it is skipping.
There is full support for
neovim. Tests will never block and will be completely asynchronous. When the test run ends the familiar green (or red) bar will be displayed.
Some changes where made as well to support interactive terminal sessions (when using
--pdbfor example) to make use of the terminal support from
warning: When calling a test, the user needs to wait until that test ends before calling another test, otherwise, the plugin will kill the first in order to call the last one.
Custom executable ^^^^^^^^^^^^^^^^^ By default, the plugin uses
py.testas the executable to run tests. Some Linux distros mangle the name to provide both Python 3 and Python 2 variants which forces one to pick a different name for the executable.
This can be customized with either the filename of the executable or the path to the executable needed. For example, for a
py.test-3name, it could be set in this way::
let g:pytest_executable = "py.test-3"
Test directory ^^^^^^^^^^^^^^ By default the project test directory is
tests(i.e. test files are assumed to be in
/path/to/project/test). The global variable
pytest_test_dirmay be used to change this, for example::
let g:pytest_test_dir = 'test_suite'
configures the test directory to be
Test file ^^^^^^^^^ By default the test file is
tests.py.The global variable
pytest_test_filemay be used to change this, for example::
let g:pytest_test_file = 'test_myproj.py'
configures the test file to be
/path/to/project/tests/test_myproj.py(assuming the default value for the project test directory)
MIT Copyright (c) 2011-2015 Alfredo Deza
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.