Статьи

Проверка Doctest в реальном времени в Vim

Vim потрясающий редактор.

Одна вещь, которая меня убивает, это «цикл» — цикл перехода от Vim к консоли, чтобы попробовать то, что я только что написал, затем обратно к Vim, чтобы исправить то, что я только что написал, затем обратно к консоли, чтобы Попробуйте еще раз. Больше всего досадно, что этот цикл обычно предназначен для мелочей, которые многие современные IDE могут уловить в режиме реального времени, как, например, версия пресловутой забытой точки с запятой для каждого языка программирования. Например, в Python я часто забываю двоеточия после блоков или как-то портит отступы.

Все, что я могу сделать, чтобы поймать глупость на раннем этапе и не тратить драгоценные минуты в режиме Fix-Try, неоценимо. Вот где плагин Vim  Syntastic  действительно сияет. Syntastic запускает любой код или компилятор для вашего кода, когда vim пишет файл. Затем он дает вам красивую яркую стрелку слева, говорящую  ЭЙ ГЛУПЫЙ . Что здорово. Вы сразу видите, где вы ленивый.

Для Python инструмент для проверки мусора / ошибок, который по умолчанию используется в синтетике, — это  Flake8 . Flake8 объединяет проверку ошибок и стиля Python (против  PEP8 ) в один инструмент. Он рассказывает вам об ошибках, которые вам обязательно нужно исправить (пропуски двоеточий и что-то еще), но также не даёт вам покоя о том, чтобы ваш код был последовательно стилизован на основе PEP8. Вместе Flake8, Syntastic и Vim предоставляют вам удивительный набор инструментов для быстрой разработки Python. Мои ошибки сразу же обнаруживаются и исправляются, и я провожу меньше времени в цикле исправлений между Vim и консолью.

Хотя есть один ингредиент, который, кажется, кричит, чтобы быть добавленным к этому убийственному комбо — интеграция doctests Python  . Если вы незнакомы, doctests обеспечивает очень низкий барьер для входа в метод разработки базовых тестов вокруг класса или функции Python. В Python довольно типично разрабатывать класс и переходить к интерактивной оболочке, чтобы опробовать свое новое творение. Поэкспериментируя с наиболее очевидными случаями в оболочке Python, вы можете очень быстро увидеть, работает ли ваш код в основном. Doctests фиксирует ваш опыт в оболочке, создавая некоторые базовые тесты в качестве примеров использования в строке документации класса или функции:

class Adder(object):
    """
    Doctests examples, showing usage as if 
    Adder were used in the console:
    >>> a=Adder(2,3)
    >>> a.add()
    5
    >>> b=Adder(3,3)
    >>> b.add()
    5
    """

    def __init__(self, x, y):
        self.x = x
        self.y = y

    def add(self):
        print self.x + self.y

В приведенном выше примере есть 2 документа для класса Adder. Все после >>> обрабатывается так, как будто оно введено в оболочку Python. Результирующий вывод (возвращенный или, в данном случае, напечатанный) в оболочке Python будет выводиться на следующей строке. Первый doctest (добавление 2 и 3) пройдет. Последний, однако, должен потерпеть неудачу (3 + 3! = 6).

Doctests прекрасно сочетается с быстрым прототипированием и экспериментами, для которых Python часто идеально подходит. Они не могут и не должны заменять сотни подробных юнит-тестов, но они хороши, когда вы хотите, чтобы что-то работало достаточно быстро.

Что сделало бы их еще более мощными, если бы мы могли интегрировать их с комбо Vim / Syntastic / Flake8. В идеале мы могли бы беспрепятственно интегрировать сбои doctest с другими ошибками Syntastic, чтобы в интерфейсе Syntastic / Vim все ошибки тестирования / ошибки синтаксиса / проблемы стиля обрабатывались одинаково. На самом деле это  именно то, что я сделал ! В моей экспериментальной развилке Flake8 я добавил довольно элементарный прототип первой итерации для запуска документов и демонстрации их сбоев, выводя их в Flake8:

Я сделал это с помощью модуля doctest Python. В данный момент код довольно предварительный, он использует API тестового модуля  doctest  для запуска тестов, а затем анализирует вывод с помощью некоторых регулярных выражений. Если вам интересно, как работать с этим API, вы можете проверить  этот файл, в  котором есть мясо самого doctest, работающего по указанному пути. Поскольку этот код зависит от результатов анализа, я не уверен, насколько хорошо он будет работать вне используемой строки Python 2.7. Если у меня есть время, и это продолжает казаться полезным, я перейду к  расширенному API doctest,  который должен быть более переносимым.

Я установил эту первую итерацию локально, чтобы попробовать ее. Конечно, это кажется потрясающей идеей, но мне любопытно посмотреть, насколько хорошо это работает на практике. Целесообразна ли бесшовная интеграция с другими ошибками Syntastic? Или нам нужен более  специфичный для теста плагин Vim ? Должны ли ошибки тестирования быть более подробными? Или нужно действительно переключиться на более отладочную среду вне режима редактора, чтобы получить исчерпывающую информацию о сбое теста? Подойдет ли такой подход для более глубоких традиционных структур модульных тестов? Испытания займут много времени, чтобы производительность записи vim упала?

Если вам интересно, я советую вам установить Syntastic, а затем попробовать мою развилку Flake8 (установить через distutils) и сообщить мне, что вы думаете (и что более важно, с какими ошибками вы сталкиваетесь). Вы можете обнаружить, что предпочитаете его ванильной версии, если используете много тестов. Вы можете обнаружить, что я чокнутый. В любом случае я хотел бы услышать от вас, что вы думаете.