# Оглавление



1. [Введение][1] (vim\_lib)
2. [Менеджер плагинов без фатальных недостатков][2] (vim\_lib, vim\_plugmanager)
3. [Уровень проекта и файловая система][3] (vim\_prj, nerdtree)
4. [Snippets и шаблоны файлов][4] (UltiSnips, vim\_template)
5. [Компиляция и выполнение чего угодно][5] (vim-quickrun)
6. [Работа с Git][6] (vim\_git)
7. [Деплой][7] (vim\_deploy)
8. **Тестирование с помощью xUnit** (vim\_unittest)
9. Библиотека, на которой все держится (vim\_lib)
10. Другие полезные плагины

Мне еще не приходилось работать в компаниях, которые тестируют свой код так, как это положено делать для последующего сопровождения и рефакторинга. В России даже крупные IT компании избегают процесс модульного тестирования, не говоря уже об общесистемном, что приводит к тоннам затхлого и окаменевшего кода. Да, я считаю, что тестируемый код, это качественный код, но почему же люди этого избегают? Как я понял, причины две:

* Незнание методологий и инструментов тестирования
* Сложность в запуске тест-случаев (test-case)

Первая проблема вне темы этой статьи, а вот вторую, особенно для пользователей редактора Vim, я постараюсь здесь решить. [Red line][8]

[1]: http://habrahabr.ru/post/259701/
[2]: http://habrahabr.ru/post/259725/
[3]: http://habrahabr.ru/post/259995/
[4]: http://habrahabr.ru/post/260591/
[5]: http://habrahabr.ru/post/261179/
[6]: http://habrahabr.ru/post/261783/
[7]: http://habrahabr.ru/post/263487/
[8]: http://habrahabr.ru/post/264297/#habracut