Комментарии 17
К чему этот бессмысленный импорт? Есть же наш исконный подход.
Тесты в любом случае честно должны выводить «пальмовое масло не обнаружено».
Тесты в любом случае честно должны выводить «пальмовое масло не обнаружено».
0
Смысл таки есть. С модулем, даже чужие тесты (что, собственно, и было важно) будут проходить успешно.
+7
Срочно читать про исконно русский подход — oldmann.livejournal.com/125252.html
+1
Как-то одновременно и очень тонко, и очень толсто.
+37
А расскажите первопричину тролинга, можно ссылку на новость(или что там), а то выпал из контекста.
+2
Все это вокруг скандала с дизельными двигателями. Довольно подробный обзор на GeekTimes
0
И вообще не про TDD. Хоть бы не позорились. (Я про авторов данного опуса.)
-3
TDD по-Фольксвагеновски?! Это же TDD по-жабоскриптовски! [смех за кадром]
-14
У нас в проекте что-то около 1500 тест-кейсов. ЧМДНТ?
0
Цифра 1500 ни о чём мне не говорит. Вы бы лучше рассказали, как часто эти кейсы пропускают незамеченными 'регрессионные' баги? И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка? Вот как вы это скажете, тогда можно будет эти цифры сравнить с проектами на других языках и платформах.
Хотел бы напомнить, что один из принципов, благодаря которому TDD работает — это то, что минимальный разумный код, затыкающий новый тест, обычно является неплохим решением задачи, а другой — то, что вызванные добавлением нового юнит-теста изменения всегда достаточно локальны. Обе этих фактора страдают, если речь идёт о Javascript, где для реализации функциональности очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения, и всё это вместе считается хорошей практикой разработки. По-моему, глупо отрицать то, что каждый шуточный модуль «фольксваген», который хакает чужой код, чтобы обмануть тесты — это камень в огород платформы, демонстрирующий её очевидные слабости. Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Хотел бы напомнить, что один из принципов, благодаря которому TDD работает — это то, что минимальный разумный код, затыкающий новый тест, обычно является неплохим решением задачи, а другой — то, что вызванные добавлением нового юнит-теста изменения всегда достаточно локальны. Обе этих фактора страдают, если речь идёт о Javascript, где для реализации функциональности очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения, и всё это вместе считается хорошей практикой разработки. По-моему, глупо отрицать то, что каждый шуточный модуль «фольксваген», который хакает чужой код, чтобы обмануть тесты — это камень в огород платформы, демонстрирующий её очевидные слабости. Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
+2
> Цифра 1500 ни о чём мне не говорит. Вы бы лучше рассказали, как часто эти кейсы пропускают незамеченными 'регрессионные' баги?
Последний критикал в продакшене был, на моей памяти, примерно год назад. Так что затрудняюсь назвать процент.
> И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка?
Не совсем понял вопрос. «Бубен и долгая отладка» возникают в подавляющем большинстве случаев из-за некорректного или нестандартного поведения какого-то браузера, а этот вопрос примерно перпендикулярен и JavaScript, и TDD.
> Обе этих фактора страдают, если речь идёт о Javascript
И каким же образом страдают?
> очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями)
Что мешает в любом другом языке беззастенчиво ломать чужой объект, я не очень понимаю. Поясните?
> и всё это вместе считается хорошей практикой разработки
Кем считается? Вами?
> это камень в огород платформы, демонстрирующий её очевидные слабости
Пока я не очень понял, что здесь «очевидная слабость платформы». Поясните?
> Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Боюсь, проблема не в шутке, а в вашем замечательном умении обобщать.
Последний критикал в продакшене был, на моей памяти, примерно год назад. Так что затрудняюсь назвать процент.
> И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка?
Не совсем понял вопрос. «Бубен и долгая отладка» возникают в подавляющем большинстве случаев из-за некорректного или нестандартного поведения какого-то браузера, а этот вопрос примерно перпендикулярен и JavaScript, и TDD.
> Обе этих фактора страдают, если речь идёт о Javascript
И каким же образом страдают?
> очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями)
Что мешает в любом другом языке беззастенчиво ломать чужой объект, я не очень понимаю. Поясните?
> и всё это вместе считается хорошей практикой разработки
Кем считается? Вами?
> это камень в огород платформы, демонстрирующий её очевидные слабости
Пока я не очень понял, что здесь «очевидная слабость платформы». Поясните?
> Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Боюсь, проблема не в шутке, а в вашем замечательном умении обобщать.
0
очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения
Постойте, но ведь если он залезет не туда, то сломаются другие тесты; это же TDD! Так в чем проблема?
0
Ага, а потом штрафы ны 36 млрд в Европе только одной (-:
+2
Я так и не понял из статьи, в чем приемущество их подхода перед обычным TDD в стиле Кента Бека?
А, посмотрел примеры, можно не отвечать :)
А, посмотрел примеры, можно не отвечать :)
+3
Возможно Вам следует почитать ветку комментариев от сюда?
0
<irony>TDI по-Фольксвагеновски</irony>
+2
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
TDD по-фольксвагеновски