Основная суть лекции: 1. Тесты в начале позволяют понять что требуется от метода перед его написанием (это хорошо, так как правильно сформулированный вопрос - уже половина ответа) 2. Наличие теста перед реализацией позволяет сузить фокус цели с написать "крутой" или "сложный" метод до "написать метод, который пройдет тест" (это убирает эмоциональный фон) 3. Если тесты все-равно придется писать - делать их в начале - психологически разгружает (сначала съешь лягушку/самое нелюбимое сделай сначала). Сделал тест и дальше только кайфуй от реализации 4. После того как метод написан - нет уверенности что метод работает правильно и учитывает весь контекст приложения. Для полной уверенности нужен тест. Это означает что, после написания приложения, необходимо написать тест(сменить контекст), затем протестировать приложение, после чего, если найдены ошибки в новом методе - исправить их(сменить контекст обратно). Тесты в начале позволяют исправить ошибки в потоке, без переключения контекста. Это экономит силы и психологически награда(всплеск дофамина) за написанный и работающий метод приходит быстрее. 5. Тесты необходимо регулярно рефакторить с целью сделать их максимально понятным, чтобы они могли служить "документацией в действии". Что тестируется и что ожидается на выходе должно быть понятно с первого взгляда.

Лайк за монтаж видео 👍🏼

Странный аргумент про "1 раз открывал хром". Для меня прокликивание сайтика (фронтенд) намного интереснее и приятнее, чем тупо день пялится в код в вскоде. Когда видишь результат, то сразу в голову приходит много идей, что надо доделать, изменить, доработать. И появляется хоть какая-то уверенность, что оно работает как задумано. С тестами нет ни удовольствия (не вижу как работает сайт), ни уверенности (может я тесты криво написал и их проходит такой же кривой код). Тесты делаю халатно гпт-чатом, лишь бы были. Польза - чтобы видеть фейлы при каких-то совсем тупых сценариях, типа случайного удаления/перезаписи каких-то файлов в гите коллегами или смене формата какой-то апишки.

TDD хороший подход, но только для определенного функционала с которым прикладной программист сталкивается крайне редко как правило это алгоритмические задачи парсинг/компиляция различные структуры данных и алгоритмы ядро бизнес логики ... и тому подобные вещи упарываться и разрабатывать через TDD буквально все, ну не знаю

Супер! Крутое выступление 🔥

19:37 - с TDD инкрементно увеличивается количество кода которое необъходимо поменять при изменении. TDD Это как строительные леса - помогают при разработке, но удлиняют время и сложность общего кода (тесты + сам код)

Я дико извиняюсь, но можно ли доверять мнению программиста, который полагает, что число "2" не простое?...

Я надеюсь что TDD станет стандартом индустрии разработки. Хороший код с которым приятно работать рождается именно там.

TDD - это полезно, но здесь докладчик его переоценивает и не обосновывает его плюсы. Например, про оптимальную архитектуру: 1. Почему архитектура на основе TDD будет обязательно оптимальна? 2. 100 джунов и 100 сеньёров пришедших из других языков и фреймворков - напишут 200 разных «оптимальных» архитектур. 3. Выбор инструментов (ЯП, фреймворки, либы) очень сильно влияют на код и его архитектуру - и TDD здесь никак не помогает. Например, в практической части показаны тесты на Redux. А почему TDD не сказал автору, что Redux - не очень хороший менеджер состояния? 4. Ещё есть кривой нейминг, который испортит код, его архитектуру и понимание. И TDD тут тоже не помощник. Не нужно переоценивать - это идёт во вред популяризации TDD.

Refactoring-Oriented Software Engineering. Что-то ничего существенного по этой теме не нашел. Поделитесь ссылками, кто в теме.

TDD - методология защиты от программистов низкой квалификации . Лучшие продукты создавались вообще в других парадигмах)

унижение ручного тестирования итт)

всё это хорошо, но нет всё упирается в жёсткий перфоманс, и всякие тдд вообще не подходят

учиться можно У а не От