С Леоновым про TDD

-3. Некоторые вещи - РЕАЛЬНО ЖЁСТКО написаны. Не принимайте это лично на свой счёт. Просто "такой стиль".

-2. Тут не БУДЕТ ВООБЩЕ никаких ПРИМЕРОВ кода. Лишь "вода" и "поток сознания". Если понадобятся примеры кода - буду писать их отдельно.

-1. Наверное понадобятся "разъяснения и дополнения". Я - готов к ним.

0. Буду отвечать "в режиме спринта". Вдохнул - начал писать - закончил писать - выдохнул. Может быть где-то напишу откровенный бред, но вы его - корректируйте.

18.12.2013 17:13, Vsevolod Leonov пишет:

Отнеситесь, пожалуйста, с юмором. J

1. Можно в блоге написать что-то вроде "как меня достал Леонов своими тупыми вопросами о тестах. Как можно не понимать простых вещей?"? Раздуем так сказать "КОНФЛИКТ"?

2. Вот смотрите. Есть "банда четырёх", а мы с вами похоже - "два придурка". Один придурок не понимает "зачем нужны тесты", а второй придурок - не понимает - "как можно не понимать "зачем нужны тесты"". В этом ключе и поведём дальнейший разговор. Ок?

3. Отбросим "формальности" и "интеллигентность" (которой у меня в помине не было). Будем "резать правду-матку". Ок?

Test Driven Development или битый небитого везёт

4. Давайте "сразу определимся". Я НЕ ИСПОЛЬЗУЮ TDD в его классическом понимании. Как и не использую UML (про который мы уже говорили и разговор о котором Леонов своей "кармой" прямо скажем "испортил" (не слишком резко?)).

Так вот! ЕЩЁ РАЗ! Для непонятливых.

Я НЕ ИСПОЛЬЗУЮ TDD в его "классическом понимании".

Чтобы потом не говорили "Люлин не читал википедию" (хотя Люлин её конечно читал, но она ему - "нафиг не упала") и не "тыкали носом" во что-то "типа Лармана" (Лармана я кстати - ПЕРЕЧИТАЛ! ОТКРОВЕНИЙ - не нашёл).

Посему!

Ещё раз! Для СОВСЕМ непонятливых.

Я НЕ ИСПОЛЬЗУЮ TDD. Я использую СИНТЕЗ подхода из TDD и "свои собственные мысли".

Я КРИТИЧЕСКИ ОЦЕНИВАЮ мысли умных людей.

И беру из них "то что помогает работе" и выкидываю "то что работе МЕШАЕТ".

И именно этот "синтез" мы далее по тексту будем понимать под "акронимом" TDD.

Ок?

TDD - это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

5. Тут всё зависит от ОПРЕДЕЛЕНИЙ - что "голова", а что "ноги". И как известно - САМЫЙ НАУЧНЫЙ спор это спор о терминах.

6. " Конечно, методика испытаний имеется в виду при проектировании" - ВОТ ИМЕННО - "МЕТОДИКА ИСПЫТАНИЙ". В софтверной инженерии её к сожалению - НЕТ (в ПРОМЫШЛЕННЫХ МАСШТАБАХ).

7. "Генетически ущербных?" - ИМЕННО ТАК. "ОНИ" (мы) почему-то решили, что ЛУЧШЕ ДРУГИХ инженеров, которые например делают велосипеды.

8. " Сами себя таким не считаете?" - СЧИТАЮ. И ИМЕННО поэтому и стремлюсь ВСЕМИ СИЛАМИ стать "ДРУГИМ". Стать ЛУЧШЕ. Не считать себя ИСКЛЮЧЕНИЕМ из ОБЩЕЙ инженерии. "Ах блин Я - ТВОРЕЦ". Нифига не ТВОРЕЦ. Ремесленник! Не более того. И ВСЕ программисты - РЕМЕСЛЕННИКИ (за исключением ЕДИНИЦ).

И это надо ОСОЗНАТЬ, ПОНЯТЬ и СМИРИТЬСЯ с этим.

И стать ИНЖЕНЕРОМ.

С БОЛЬШОЙ БУКВЫ.

А для этого нужны - "допуски, чертежи, и методика испытаний".

TDD - сковывает инициативу разработчика. Уже не сам разработчик контролирует процесс, а задание «валится на него снеговыми комками»? Нет ли психологического дискомфорта? Программист у нас теперь не творец, а бездумная машина реализации придуманного не им функционала?

9. НЕТ! Не сковывает! НАОБОРОТ - позволяет "работать больше" :-) Вместо ОДНОГО класса "приходится" писать ДВА - сам ПРОЕКТНЫЙ класс и ТЕСТ к нему. TDD это как раз для ИНИЦИАТИВНЫХ людей. Которые ЛЮБЯТ свою работу. А БЕЗДЕЛЬНИКИ - нам ни к чему. БЕЗДЕЛЬНИКИ - могут дальше не читать.

10. Ещё как КОНТРОЛЛИРУЕТ! Более чем контроллирует. Сам себя "бьёт по рукам". И заставляет "шевелиться серые клеточки".

11. ДИСКОМФОРТА - НЕТ. Наоборот - есть ощущение СТАБИЛЬНОСТИ (привет Путину) и УВЕРЕННОСТИ в завтрашнем дне.

12. НЕТ! Программист - "ТВОРЕЦ". В смысле - ремесленник :-) Он "творит" - в "ДВА РАЗА БОЛЬШЕ". (Лентяев ведь мы скинули со счетов).

На самом деле - хрен два - "В ДВА РАЗА".

На самом деле - МЕНЬШЕ. Почему? Постараюсь объяснить ниже.

TDD - ставит во главу угла не качество реализации, а сиюминутные фичи. Как можно говорить о качестве кода? Об архитектуре системы? Мы на выходе с точки зрения программного кода получаем «салат оливье» - механическую смесь разных на вкус и цвет мелкопорезанных кусочков? Вы верите, что из винегрета, сложенный большой кучкой может символизировать собой архитектурное совершенно и конструктивное качество?

13. БРЕД!!! Именно КАЧЕСТВО и СТАБИЛЬНОСТЬ (ещё привет Путину) ставится во главу угла.

14. Как говорить о "качестве"? ОЧЕНЬ просто - "есть фича" и "есть тест" проверяющий эту фичу. При таком подходе мы ГАРАНТИРОВАННО получаем качественную (с точки зрения ТЗ) систему.

Что НЕ ПОПАЛО в ТЗ, то и не попало в тесты. Но это уже - "проблема заказчика".

15. Про архитектуру... Давайте подумаем - "а что есть архитектура"? Действительно - что есть архитектура? Про UML ведь мы тут говорить не будем?

Так вот...

Архитектура это не есть "что-то универсальное". И не есть "серебряная пуля".

Я САМ - ХОРОШИЙ АРХИТЕКТОР (к чёрту скромность) и я обладаю УНИКАЛЬНОЙ АССОЦИАТИВНОЙ ПАМЯТЬЮ (опять же - к чёрту скромность). Коллеги - НЕ ДАДУТ СОВРАТЬ. Меня "ночью разбуди" - я расскажу - что и где находится - в каком модуле и не какой СТРОЧКЕ.

Так вот!

При всём при этом даже Я (большая буква - не случайно) - ПОЛНУЮ КАРТИНУ - НИКОГДА не помню.

НИКОГДА!

Архитектура (если не брать UML И "чертежи") - это набор "проектных решений".

Это "калейдоскоп решений и фич". И ТЕСТОВ - "их проверяющих".

Точнее - "матрёшка калейдоскопов".

И все эти калейдоскопы связаны логическими цепочками, которые "можно восстановить в памяти".

Причём тут тесты?

А вот при том - "тесты это ПРИМЕР ИСПОЛЬЗОВАНИЯ конкретного кода и КОНКРЕТНЫХ проектных решений".

Если что-то ЗАБЫВАЮ - мне ДОСТАТОЧНО посмотреть на тест, чтобы это вспомнить.

При этом тесты - БОЛЕЕ стабильны и ИНВАРИАНТНЫ нежели "реальный проектный код". Код перерождается. Эволюционирует. Умирает.

С тестами же это происходит ГОРАЗДО реже.

TDD – некий бич, которым хлещут непокорных IT-рабов? Это что – некий вид «управы» на непокорных, гордо именуемых «разработчиками»? Вы, разрабочтики, не должны думать. Ваша дело – тянуть лямку, выполнять план по валу! Смотри на тесты, данные тобой свыше, и не вздумай проявлять инициативу!

16. Значит так... "Руководству", директорату и (тем более) заказчикам - РЕАЛЬНО НАПЛЕВАТЬ - какие технологии используются (за редкими исключениями).

По большому счёту - НИКОГО НЕ ПАРИТ - какие используются технологии и что там "внутри" делают разработчики. Используют они RUP, TDD/ШмеДД, Agile/СуперАгиле или что-то иное...

НИКОГО НЕ ПАРИТ!!!

Ещё РАЗ - НИКОГО НЕ ПАРИТ.

Всем выше перечисленным "стейкхолдерам" - ВАЖЕН РЕЗУЛЬТАТ. А не ПРОЦЕСС!!!

"Энтропия"!!! Это функция "состояния", а не "процесса".

Никакой здравомыслящий начальник НЕ БУДЕТ "навязывать" TDD.

Это не В ЕГО ИНТЕРЕСАХ.

Ещё раз!

Это не в ЕГО ИНТЕРЕСАХ.

Ему нужен РЕЗУЛЬТАТ. А не "раздражение разработчиков" типа - "вот этот умник опять какие-то навомодные фишки нам навязывает".

УМНЫЙ начальник... Ну РЕАЛЬНО УМНЫЙ - может лишь "сделать так", чтобы разработчики "сами" почувствовали, что "им это надо".

Это - ЕДИНСТВЕННЫЙ путь. Иначе - ТУПИК!

17. НЕТУ "тестов данных свыше". Тесты это "ВНУТРЕННЕЕ" дело разработчиков. И чем лучше тесты и чем их больше, тем разработчики "крепко спят". И тем меньше они "вызываются на ковёр".

Тесты это не средство "управления".

Тесты это средство "спать спокойно". Для РАЗРАБОТЧИКОВ, а не для "начальников".

ЕЩЁ РАЗ - Тесты это средство "спать спокойно". Для РАЗРАБОТЧИКОВ, а не для "начальников".

TDD – попытка некомпетентных и далёких от кодирования людей продвигать свою, чуждую разработчикам идеологию… своё, часто неправильное видение стратегии развития продукта.

18. ЕЩЁ РАЗ!

Для непонятливых.
Тесты НЕ ДИКТУЕТ "директорат", руководство или заказчики.

Тесты - это СРЕДСТВО РАЗРАБОТКИ.

Тесты это "внутренняя кухня" разработчиков и "группы качества".

Все остальные "стейкхолдеры" оперируют ТЗ. Ну или "экранами". Максимум...

19. Тесты и "стратегия развития" - НИКАК не соотносятся.

Допустим, меня обязали следовать технике TDD, хотя, согласитесь, очень многие люди комфортно чувствуют себя без этого. Ну и что это даёт по сравнению с нормальной техникой, когда «запланировали – реализовали – сделали тесты – протестировали»? Просто «красивая сказка» для начальника «мы используем передовые подходы?»

20. ЕЩЁ раз!

"Обязать" использовать тесты - НЕВОЗМОЖНО. Можно лишь только "уговорить".

21. Если кто-то чувствует себя комфортно БЕЗ тестов, то значит, что:
 а. Его проект не такой сложный.
 б. Он Всё тестирует на реальных пользователях. (не повезло им)
 в. Он гений.
 г. Он работает ОДИН.

22. Ещё раз. "Сказки" - НЕТ. "начальству" - ВСЁ РАВНО.
Начальству нужен РЕЗУЛЬТАТ, СРОКИ и КАЧЕСТВО продукта.

Напахал я тестов. Начал под них (скрепя сердце) подгонять функциональный код. Выясняется… потом, что тест придуман неправильно. Я поработал впустую?

23. Не НАДО ничего "НАПАХИВАТЬ".

"Алгоритм" - ПРОСТЕЙШИЙ - читаем ТЗ, и реализуем "фичи".

ОДНА "фича" - ОДИН "тест".

И так - ИТЕРАТИВНО.

Фича - порождает фичи, а фичи порождают тесты.

"Матрёшка".

"Калейдоскоп".

XP!!! Если хотите.

KISS-принцип.

А не бывает такого, что «тесты», которые приобрели вид «жёсткого задания», начали противоречить друг-другу?

24. О! Это мой ЛЮБИМЫЙ вопрос! Это "ГЕНИАЛЬНЫЙ" вопрос.

Только идиот НЕ ПОНИМАЕТ ответа.

Давайте ПОДУМАЕМ!

Что ОЗНАЧАЕТ фраза "тесты начали противоречить друг-друг".

Давайте ВКЛЮЧИМ ИНТЕЛЛЕКТ!

Если тесты "противоречат друг-другу" это означает, что:
 а. ТЗ недостаточно ПРОРАБОТАННО.
 б. ТЗ ПРОТИВОРЕЧИВО.

Тут надо "сказать СПАСИБО тестам" и ВЕРНУТЬСЯ к проработке ТЗ.

TDD – потеря времени. Давайте уж сначала напишем код, а потом будем его тестировать. Любое хождение «задом-наперёд», ненатуральный порядок разработки, даже если не сказывается на качестве, обязательно вызовет «тормоза».

25. Хорошо. Давайте напишем код. Напишем. Покоммитим его в CVS/SVN. И что?

Мы свою работу сделали?

Типа "как повезёт"? Прокатит/не прокатит?

Можно и так.

Только потом тебя "поднимут с постели" и спросят "что за хрень ты тут написал?"

Так?

Можно ведь по-другому - "написать код" и "ПРОВЕРИТЬ его". А как мы его будем проверять?

"Тупым" протыкиванием?

А если для "протыкивания" надо сделать 20-ть шагов? А если 100? А если "данных нет"? А если "смежники не готовы"?

Не лень?

Не проще ли "написать тест" хотя бы для отладки?

С придуманными "из головы" входом и выходом.

По-моему - ПРОЩЕ.

А если тест УЖЕ написан и использовался для ОТЛАДКИ, то почему не включить этот тест в "ночную сборку"?

TDD – способ поставить разработчика в унизительное положение. «Битый небитого везёт». Программист работает «от чувства вины» в перманентном состоянии нереализованности поставленной задачи.

26. НАОБОРОТ!

У программиста всегда есть "реперные точки".

Тут вот я написал тест. Он не проходит.

Тут я реализовал функционал.

Тест стал ПРОХОДИТЬ.

Я всё покоммител в CVS/SVN.

Я свою работу СДЕЛАЛ и "могу спать спокойно".

TDD – нет ли ощущения, что программист всё время решает «обратную задачу»? Или разработчик – двоечник, подгоняющий решение под ответ задачи?

27. А программисты - ВСЕГДА решают "обратную задачу". Ну или "строят коня в вакууме".
28. Нет - НЕ ДВОЕЧНИК. Просто - "обычный человек". Который НЕ МОЖЕТ предусмотреть ВСЁ. Но зато то, что он ПРЕДУСМОТРЕЛ - ГАРАНТИРОВАННО работает.
29. Есть и другие люди. Но они - ГЕНИИ. Их - МАЛО.

TDD – разработка в зазеркалье. Мы выполнили тесты, что не есть гарантия безошибочности. Кто отвечает за качество тестов?

30. Ещё раз!

ТЕСТЫ это не средство "битья по рукам".

ТЕСТЫ это средство - "спать спокойно".

31. ГАРАНТИИ "полной безошибочности" - НЕТ.
Есть лишь гарантия того, что разработчик ПРАВИЛЬНО понял ТЗ и реализовал его так как ПОНЯЛ.

TDD – телега впереди лошади. Лошадь постоянно тыкается мордой «в задний бампер», не видя ничего впереди себя. Как можно говорить о продумывании функционала в целом на уровне архитектуры системы, когда впереди – вдаль до самого горизонта – просто свалка потребностей?

32. Вот тут ОПЯТЬ давайте вернёмся к "самому научному спору".

Давайте "ОПРЕДЕЛИМ ТЕРМИНЫ".

Что есть "телега", а что "лошадь".

Если мы почитаем википедию - мы увидим "полный бред".

И я об этом - ПИСАЛ - http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html

и тут - http://programmingmindstream.blogspot.ru/2013/11/tdd.html

"Как можно тестировать то ЧЕГО НЕТ"?

Я САМ задавался этим вопросом.

Пока не ПОНЯЛ одной ПРОСТОЙ ИСТИНЫ:
"лошадь" - это ТЗ.
"телега" - это КОД.

А что есть ТЕСТЫ?

Тесты это - "оглобли" которыми "лошадь" привязана к "телеге".

Т.е. - ВЕДЁТ - ТЗ, а тесты - "тянут за собой" код. И ПРОВЕРЯЮТ его соответствие ТЗ. И то что "код едет в ту же сторону, что и ТЗ".

Нету ни TestFirst! Ни CodeFirst!

НЕТУ!

Для непонятливых - Нету ни TestFirst! Ни CodeFirst!

ЕСТЬ - ТЗ-First!

ВСЁ - "растёт ногами" из ТЗ и ТЕСТЫ и код и АРХИТЕКТУРА.

И ПОТОМ - ArchitecrureFirst!

Т.е. цепочка разработки выглядит так:
 ТЗ -> Набросок архитектуры -> Тест -> Код

А дальше возможны все разные варианты:
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код -> ТЗ -> Архитектура -> Тест -> Код

и т.д. и т.п.

First - это - ТЗ и набросок архитектуры - дальше начинается - "итерационная разработка".

И что - особенно ВКУСНО - это то, что как только мы написали тест - нам НЕ НАДО думать - "а где проверять работоспособность нашего класса".

Мы УЖЕ настроили всю инфраструктуру для его тестирования и проверки.

ИМЕННО в этом и заключается слово Driven в TDD.

Ладно, есть на свете «извращенцы». Тогда хоть как можно облегчить страдания? Какой правильный процесс при этом?

33. Ну я - "извращенец". И ещё ещё как минимум - 6-ть человек.
34. Процесс я описал выше.

Повторю для "идиотов":

Т.е. цепочка разработки выглядит так:
 ТЗ -> Набросок архитектуры -> Тест -> Код

А дальше возможны все разные варианты:
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код
 ТЗ -> Набросок архитектуры -> Тест -> Код -> Архитектура -> Тест -> Код -> ТЗ -> Архитектура -> Тест -> Код

А какой инструментарий? Как «впрячь коня (упрямый пони на коротких ножках) и трепетную лань (мысль разработчика)?

35. Значит про "мысль". С РАЗРАБОТЧИКОМ - надо "РАБОТАТЬ". Ходить вместе курить. Поить пивом (шучу). Уговаривать. Развлекать.

Сделать так, чтобы ОН ТЕБЕ ПОВЕРИЛ.

И чтобы считал ТВОИ мысли СВОИМИ (привет Карнеги).

По-другому - НИКАК.

ЗАСТАВИТЬ - НЕЛЬЗЯ.

Как и НЕЛЬЗЯ ЗАСТАВИТЬ "писать хороший код".

Можно подарить человеку книгу Мак-Конела на день Рождения. Но НЕ БОЛЕЕ ТОГО!

НИКАКИЕ АДМИНИСТРАТИВНЫЕ меры - НЕ ПОМОГУТ. Вызовут лишь - озлобление.

Я это прошёл и НЕ РАЗ.

36. Инструментарий.

а. DUnit.
б. Доработки к DUnit - http://18delphi.blogspot.ru/2013/03/dunit.html
в. Confluence - http://ru.wikipedia.org/wiki/Confluence
г. САМОПИСНЫЙ аналог JIRA (http://ru.wikipedia.org/wiki/Jira). В ту пору JIRA была ещё "сыра" поэтому мы её не взяли. СЕЙЧАС - я думаю - взяли бы её.
д. Скриповая машина - http://18delphi.blogspot.ru/2013/11/gui.html
е. FishEye (https://www.atlassian.com/software/fisheye/overview).
ё. Доработки к Confluence и FishEye позволяющие отслеживать связь коммитов, изменений кода и строящие привязку КОНКРЕТНЫХ изменений кода к КОНКРЕТНЫМ задачам (если я получу разрешение руководства - опубликуем скриншоты). Я бы на месте нашего руководства давно бы продавал бы это как КОММЕРЧЕСКИЙ продукт.
ж. Интеграция UML и Confluence.

В каком виде и кто создает тесты? А если «роль» создателя тестов не предполагает знание программирования?

37. Тесты создают разработчики. Если речь идёт о новой функциональности.

Или тестировщики. Если речь идёт об ошибках.

И ЧАЩЕ всего - тестировщики пишут ошибку и СРАЗУ пишут к ней тест.

Тут кстати надо понимать ОДНУ ПРОСТУЮ вещь - ТЗ и ОШИБКИ в общем-то ничем НЕ ОТЛИЧАЮТСЯ друг от друга принципиально. Только лишь "зоной ответственности".

38. "А если «роль» создателя тестов не предполагает знание программирования?" - на BDD или Fit-таблицы - мы пока не "замахивались", но мы РАБОТАЕМ над этим.

TDD – это наше «всё» или Вы всё-таки признаёте ограниченность данной техники?

39. "Разруха она в головах, а не в писсуарах".

НЕТУ "ограниченности".

Есть "нежелание применять".

Или "банальная лень".

Ко всем ли системам применима техника TDD? Есть «особые случаи» или «другие подходы»?

40. НЕТ! Нету "особых случаев".

Есть что-то "что можно выкинуть", есть что-то "что можно привнести".

Но в ЦЕЛОМ - TDD - ОСТАЁТСЯ. И ГАРАНТИРУЕТ "спокойный сон".

Что привело Вас к TDD?

41. Я писал об этом тут - http://18delphi.blogspot.ru/2013/03/blog-post.html

И тут - http://18delphi.blogspot.ru/2013/03/tdd-c.html

Что по-Вашему может быть лучше, чем TDD?

42. BDD ;-) Роман Янковский "над ним работает" :-) Ссылка - http://roman.yankovsky.me/?p=1258

Ну и Fit-таблицы. Ссылки к сожалению - найти не могу...