Отнюдь, я нигде не доказывал, что тестироваться должна каждая строчка. Где же я это доказывал? Я просто обсуждал TDD и его практики. Поступать можно по-разному.
зачем писать тест для элементарной функции, длина которой едва ли больше названия теста для нее.
Это объясняется в этой статье и в комментариях к этой.
p.s. Прочитайте все мои комментарии выше и вы поймёте, что я не zealot.
Речь не идёт о 100% покрытии кода. Речь идёт о применении тех или иных практик в различных ситуациях. Единственное о чём говорит Марк — это то, что со свойствами не всё так просто «что я их тупо не тестирую, они протестируются через другие тесты».
А я говорю о том, что эти подходы имеют право на жизни. Ещё как имеют. И люди ими успешно пользуются.
Вы можете посмотреть подкасты с Роем Ошероувом и Робертом Мартином, где они используют эту технику.
if\else — это перебор, а идея минимальных приращений — нет. Смысл в том, что вы пишете ровно столько, сколько достаточно для прохождения теста. Ваш говнокод с If\else, следуя TDD необходимо отрефакторить, что отрефакториться в нормальный код. Но вы не имеете права сразу писать generic-код.
Я понимаю как всё это звучит. Но как бы всё это ни звучало странно прислушайтесь к тому, что говорят Кент Бек, Р. Мартин, Р. Ошероув, Марк Симен. Они не идиоты и далеко не все из них являются коучами.
То, что вы не готовы воспринять это — ещё не значит, что в этой практике есть что-то порочное.
Марк не издевается. Это известная практика при использовании TDD. Это и есть «маленькие формализованные трансформации». Этим пользуются и Марк и Роберт Мартин и Рой Ошероув (и я и много кто ещё, полагаю).
мой код полностью отвечает придуманной мне архитектуре.
Либо вы привираете, либо пишите хэлоу-ворлд, либо ваш заказчик мёртв. Последний маловероятный вариант — вы опровергли утверждения о том, что невозможно предвидеть всё наперёд, невозможно построить приложение полностью удовлетворяющее SOLID-принципам (ведь приложение, полностью удовлетворяющее SOLID-принципам — оксюморон).
Вот тут-то и ошибка.
На листке бумаги — рисунки, а не архитектура. Дядя Боб ни раз повторял, что всё, что он рисует на листках не реализуется в коде в реальности.
Архитектура — это код, форма, которую он принимает. Здесь речь идёт о практике TDD. Эта практика подразумевает, что архитектура выращивается через тесты.
чем на механическое вбивание новых тестов для тривиальных функций
Само построение предложения подразумевает, что вы говорите не о TDD, а об обыкновенном Unit Testing. У вас функции — не результат тестов. У вас тесты — аппендикс, мешающий написанию кода.
То что пишет программист это модульный тест.
Программисты не пишут интеграционные тесты? Да ну?)))
Я не сторонник догм. Однако мне всегда казалось, что TDD пытается механизировать процесс написания кода. Именно об этой механизации я и напоминаю в комментарии выше. А насколько догматично стоит подходить к TDD — дискуссионный момент. Собственно, здесь мы видим заочную дискуссию дяди Боба и Марка.
Вы ведь пишите код не потому, что у вас есть тест. Вы пишите тест потому, что у вас есть необходимость в функционале, который вы знаете изначально.
Изначальный функционал — абстракция, лежащая на бумаге. Только код является функционалом и архитектурой. Таким образом, перенести абстрактное корректное «изначальное поведение», в код — трудная задача. Эту задачу призван решать TDD и TDD пытается формализовать процесс переноса «абстрактного корректного изначального поведения», делая тест причиной, а код следствием, что согласуется с одним из основоположений TDD.
Здесь мы с вами как раз втыкаемся в проблему о которой сказал Марк Симэн в своём «обзоре» этого поста дяди Боба: «что есть тривиальный?»
В целом, я с вами согласен.
На моей первой машине в 94-м (или 96-м, уже не помню) году стоял Pentium I 100Mhz. По-моему, было там 8Мб оперативной памяти, хард с парой сотен МБ. На нём шёл Tomb Raider, а затем и Tomb Raider II, Neverhood, KKnD (кто помнит такую стратежку? :) ), StarCraft.
А затем я познакомился на нём же с QBasic. Привет тебе, Pentium :)
А если на геттер вы не напишите теста? Теста нет. Откуда вы знаете, что следующий разраб будет писать тест на этот геттер, прежде чем изменит его? Другой разраб может вообще не практиковать TDD или не любить его, но лично моя задача быть профессионалом и передать код хорошего качества, который не может быть поломан на раз каким-нибудь нерадивым программистом. Мои тесты хотя бы должны будут ему указать на то, что не всё так просто как ему кажется.
А если ваш код будет править другой разработчик? Откуда ему знать есть ли у вас тесты или нет, он просто поправит и всё.
Разумеется, тот подход, о котором говорит Кент — нормальный жизнеспособный подход.
Но интересным остаётся вопрос практики: каков механизм понимания того, что вы 99% не ошибётесь? Почему не 93%? А если 93%, то почему не 37%?
А если вы не согласны с автором — ваше право. В программировании редко встречаются абсолютные правила.
Это объясняется в этой статье и в комментариях к этой.
p.s. Прочитайте все мои комментарии выше и вы поймёте, что я не zealot.
Это подкаст Роберта Мартина.
Могу найти и подкаст Ошероува.
Речь не идёт о 100% покрытии кода. Речь идёт о применении тех или иных практик в различных ситуациях. Единственное о чём говорит Марк — это то, что со свойствами не всё так просто «что я их тупо не тестирую, они протестируются через другие тесты».
А я говорю о том, что эти подходы имеют право на жизни. Ещё как имеют. И люди ими успешно пользуются.
if\else — это перебор, а идея минимальных приращений — нет. Смысл в том, что вы пишете ровно столько, сколько достаточно для прохождения теста. Ваш говнокод с If\else, следуя TDD необходимо отрефакторить, что отрефакториться в нормальный код. Но вы не имеете права сразу писать generic-код.
Я понимаю как всё это звучит. Но как бы всё это ни звучало странно прислушайтесь к тому, что говорят Кент Бек, Р. Мартин, Р. Ошероув, Марк Симен. Они не идиоты и далеко не все из них являются коучами.
То, что вы не готовы воспринять это — ещё не значит, что в этой практике есть что-то порочное.
Марк не издевается. Это известная практика при использовании TDD. Это и есть «маленькие формализованные трансформации». Этим пользуются и Марк и Роберт Мартин и Рой Ошероув (и я и много кто ещё, полагаю).
Либо вы привираете, либо пишите хэлоу-ворлд, либо ваш заказчик мёртв. Последний маловероятный вариант — вы опровергли утверждения о том, что невозможно предвидеть всё наперёд, невозможно построить приложение полностью удовлетворяющее SOLID-принципам (ведь приложение, полностью удовлетворяющее SOLID-принципам — оксюморон).
На листке бумаги — рисунки, а не архитектура. Дядя Боб ни раз повторял, что всё, что он рисует на листках не реализуется в коде в реальности.
Архитектура — это код, форма, которую он принимает. Здесь речь идёт о практике TDD. Эта практика подразумевает, что архитектура выращивается через тесты.
Само построение предложения подразумевает, что вы говорите не о TDD, а об обыкновенном Unit Testing. У вас функции — не результат тестов. У вас тесты — аппендикс, мешающий написанию кода.
Программисты не пишут интеграционные тесты? Да ну?)))
Изначальный функционал — абстракция, лежащая на бумаге. Только код является функционалом и архитектурой. Таким образом, перенести абстрактное корректное «изначальное поведение», в код — трудная задача. Эту задачу призван решать TDD и TDD пытается формализовать процесс переноса «абстрактного корректного изначального поведения», делая тест причиной, а код следствием, что согласуется с одним из основоположений TDD.
p.s. Извиняюсь, промазал уровнем.
В целом, я с вами согласен.
А затем я познакомился на нём же с QBasic. Привет тебе, Pentium :)