Программное обеспечение, разрабатываемое в компании, довольно специфичное и предназначено для промышленных платформ (автомобильных компьютеров). Компания не раскрывает, какими инструментами пользуется при разработке; и тем более не выкладывает эти инструменты в открытый доступ, как это часто бывает среди ведущих IT компаний. Но сам инновационный подход Volkswagen к тестированию поразил всех. Этот передовой опыт несомненно заслуживает того, чтобы перенять его и внедрить также в мейнстриме нашей отрасли. И сообщество Github незамедлительно откликнулось на этот вызов. Итак, встречайте: библиотеки для поддержки TDD в стиле Volkswagen.
Актуальная информация о реализациях собрана здесь. На данный момент есть реализации для языков Ruby (даже две), JavaScript, Java, D, Go, PHP, Objective-C и Swift. Вот, к примеру, описание модуля volkswagen для JavaScript. (Другие реализации отличаются по синтаксису, но совершенно аналогичны по назначению.)
Volkswagen обнаруживает, что ваши тесты выполняются на сервере постоянной интеграции (CI) и обеспечивает их успешное прохождение.
Для чего нужно?
Если вы хотите, чтобы ваш софт был принят жителями США, хорошие результаты тестов с интеграционного сервера очень важны. Volkswagen использует так называемое «defeat device» для определения того, что проводится тестирование на интеграционном сервере, и понижает количество ошибок до приемлемого для прохождения тестов уровня. Это позволит вам тратить меньше времени на тестирование и больше наслаждаться жизнью как разработчику, которому доверяют.
В свой README файл вы можете вставить вот такой вечнозеленый бейдж для статуса сборки проекта:
В синтакисие markdown:
[](https://github.com/auchenberg/volkswagen)
Установка
npm install volkswagen
Использование
Просто включите volkswagen в любом месте вашего кода, например в основном файле с тестами:
require('volkswagen')
Статус проекта
Обнаруживаемые серверы интеграции:
Travis CI, CircleCI, Jenkins CI, Hudson, Bamboo, TeamCity, Team Foundation Server, Visual Studio Online CI, GitLab CI, Codeship, Drone.io, Buildkite, TaskCluster. А также другие серверы, которые экспортируют переменную окружения CI или CONTINUOUS_INTEGRATION.
Библиотеки для модульного тестования, тесты в которых обходятся: assert, tap, tape, chai а также любые другие тесты, которые устанавливают код возврата или выбрасывают ошибку.
Лицензия
MIT
Обратите внимание, что эффект снижения количества ошибок проявляется только при тестировании на интеграционном сервере. При запуске на машине разработчика тесты выполняются со всей строгостью. Ну и в production, ясное дело, не будет никаких отличий.
Добавить реализации для других языков и серверов интеграции приглашаются все желающие. Не забудьте добавить ссылку сюда.
Комментарии (17)
nitso
18.10.2015 23:58+37Как-то одновременно и очень тонко, и очень толсто.
nomit
19.10.2015 11:23+2А расскажите первопричину тролинга, можно ссылку на новость(или что там), а то выпал из контекста.
nitso
19.10.2015 13:01Все это вокруг скандала с дизельными двигателями. Довольно подробный обзор на GeekTimes
Rumega
19.10.2015 04:04-14TDD по-Фольксвагеновски?! Это же TDD по-жабоскриптовски! [смех за кадром]
forgotten
19.10.2015 10:11У нас в проекте что-то около 1500 тест-кейсов. ЧМДНТ?
Rumega
19.10.2015 18:25+2Цифра 1500 ни о чём мне не говорит. Вы бы лучше рассказали, как часто эти кейсы пропускают незамеченными 'регрессионные' баги? И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка? Вот как вы это скажете, тогда можно будет эти цифры сравнить с проектами на других языках и платформах.
Хотел бы напомнить, что один из принципов, благодаря которому TDD работает — это то, что минимальный разумный код, затыкающий новый тест, обычно является неплохим решением задачи, а другой — то, что вызванные добавлением нового юнит-теста изменения всегда достаточно локальны. Обе этих фактора страдают, если речь идёт о Javascript, где для реализации функциональности очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения, и всё это вместе считается хорошей практикой разработки. По-моему, глупо отрицать то, что каждый шуточный модуль «фольксваген», который хакает чужой код, чтобы обмануть тесты — это камень в огород платформы, демонстрирующий её очевидные слабости. Впрочем, толпы ?о?б?и?ж?е?н?н?ы?х? ?д?е?т?е?й? ? опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.forgotten
19.10.2015 18:37> Цифра 1500 ни о чём мне не говорит. Вы бы лучше рассказали, как часто эти кейсы пропускают незамеченными 'регрессионные' баги?
Последний критикал в продакшене был, на моей памяти, примерно год назад. Так что затрудняюсь назвать процент.
> И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка?
Не совсем понял вопрос. «Бубен и долгая отладка» возникают в подавляющем большинстве случаев из-за некорректного или нестандартного поведения какого-то браузера, а этот вопрос примерно перпендикулярен и JavaScript, и TDD.
> Обе этих фактора страдают, если речь идёт о Javascript
И каким же образом страдают?
> очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями)
Что мешает в любом другом языке беззастенчиво ломать чужой объект, я не очень понимаю. Поясните?
> и всё это вместе считается хорошей практикой разработки
Кем считается? Вами?
> это камень в огород платформы, демонстрирующий её очевидные слабости
Пока я не очень понял, что здесь «очевидная слабость платформы». Поясните?
> Впрочем, толпы ?о?б?и?ж?е?н?н?ы?х? ?д?е?т?е?й? ? опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Боюсь, проблема не в шутке, а в вашем замечательном умении обобщать.
ComodoHacker
19.10.2015 19:01очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения
Постойте, но ведь если он залезет не туда, то сломаются другие тесты; это же TDD! Так в чем проблема?
alexeygrigorev
19.10.2015 10:48+3Я так и не понял из статьи, в чем приемущество их подхода перед обычным TDD в стиле Кента Бека?
А, посмотрел примеры, можно не отвечать :)
entze
К чему этот бессмысленный импорт? Есть же наш исконный подход.
Тесты в любом случае честно должны выводить «пальмовое масло не обнаружено».
AEP
Смысл таки есть. С модулем, даже чужие тесты (что, собственно, и было важно) будут проходить успешно.
Milfgard
Срочно читать про исконно русский подход — oldmann.livejournal.com/125252.html