Много лет назад, в начале моей карьеры разработчика программного обеспечения, я перешел на новое место работы и по незнанию оказался в центре холодной войны. Несколькими месяцами ранее технический менеджер ввел политику разработки через тестирование. Одна группа инженеров приняла эту практику, в то время как другая стала категорически против. Я изо всех сил пытался понять, во что я верил, среди поляризованных мнений вокруг меня.
Спустя несколько месяцев мне удалось перебраться в другую группу и, таким образом, уйти от конфликта. Вскоре после присоединения меня попросили создать большую интерфейсную систему JavaScript. Это было время до Angular и React. Единственными моими библиотеками были jQuery и Underscore для приложения и Jasmine для тестирования. Сначала я обнаружил, что возвращаюсь к старым и комфортным привычкам не тестировать; Я попытался оставить позади холодную войну, полностью игнорируя испытания.
Но JavaScript, как известно многим инженерам, безжалостен. Я наблюдал, как мои проекты разлагаются на моих глазах до слишком знакомого мне комка, и я знал, что TDDers наверняка скажут о том, что я делаю. Мне пришлось признать, что мой подход не будет масштабироваться, и что мне придется принять участие в тестировании, если проект будет успешным. Я также не хотел закончить тем, что многие хрупкие и хрупкие тесты, на которые группа противников TDD любила указывать, чтобы оправдать свои утверждения. Я решил, что мне нужно создать правильные тесты.
Результаты превзошли мои самые смелые ожидания. В течение месяца после принятия решения о применении подхода, основанного на тестировании (при сохранении пристального внимания к архитектуре и организации), я смог очистить свой глюбол до чего-то хорошего, возможно, даже приближающегося к элегантному. Это была кодовая база, которую другие инженеры, после того как я перешел к другому проекту, смогли быстро подобрать и продолжить разработку.
С этого момента в моей карьере я был увлечен поиском лучшей стратегии тестирования для своих проектов как на рабочем месте, так и за его пределами.
Когда я впервые пришел к языку программирования Elm, я был впечатлен тем фактом, что этот молодой язык уже обладал надежной структурой модульного тестирования в виде Elm Test. Освоив основы языка, я быстро перешел к разработке стратегии тестирования приложений Elm.
Поскольку я все чаще и чаще использовал Elm Test, я не мог не заметить небольшого трения, к которому я не привык. А именно, мне приходилось переключаться между Atom и моим терминалом с помощью command-tab, чтобы запустить мои тесты. Это сильно отличалось от ситуации, к которой я привык за годы разработки PHP, Java и C #, когда тесты можно запускать внутри редактора одним нажатием командной клавиши.
Итак, я решил создать такой инструмент. Elm Test Runner ищет в вашем проекте каталог Elm с тестами и выполняет Elm Test в этом каталоге в фоновом режиме. Затем он анализирует выходные данные Elm Test в древовидной структуре и отображает все ошибки, если они есть. Я также включил инструменты для копирования семени запуска и принуждения его к определенному значению, и все это в редакторе.
Я узнал тонну о вязовой постройке Elm Test Runner. Мне пришлось применить и развить многие принципы, которые я обсуждал в своей статье Стратегии зависимостей высокого уровня в Elm. Впервые использовал порты и декодеры JSON. И, наконец, я получил практические знания о том, как создать плагин Atom в первую очередь в Elm. Elm Test Runner, естественно, представляет собой приложение Elm с минимально возможным количеством клея JavaScript, связывающего его с Atom.
Больше всего интересно было создавать Elm Test Runner, и я с нетерпением жду дальнейшего расширения его функциональности.
Вы можете установить Elm Test Runner, выполнив поиск elm-test-runner в Atom. Вы также можете найти исходный код проекта на GitHub.
