Последние лет 10 разработка с написанием тестов наперёд является сильно модной фишкой, многие компании хвастаются ей и говорят какой у них крутой процесс разработки, однако во всех местах что я работал — ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки
Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
N>Последние лет 10 разработка с написанием тестов наперёд является сильно модной фишкой, многие компании хвастаются ей и говорят какой у них крутой процесс разработки, однако во всех местах что я работал — ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Так TDD применяется к юнит, РЕСТ АПИ и прочим подобным тестам. Чтобы их применяли к UI тестам – ни разу не слышал. А не применяют их там по озвученным тобою же причинам.
N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Использовал в нескольких компаниях. Можно выделить три основных подхода.
1) Нелегально, так сказать. Когда ты сам для себя пишешь тесты, иногда даже не заливаешь их в общий репозиторий, чтобы не "наругали" за потраченное зря время В такой компании долго не проработал, что-то около 9 месяцев, поэтому не могу сказать был бы этот способ жизнеспособен на дистанции.
2) Полулегально, когда большой кровью добиваешься разрешения писать тесты для группы разработчиков (5-10). Здесь приходится давать жесткие обещания, что производительность и качество вырастут и не будет других просадок. Пришлось сильно испортить отношения с парой менеджеров. Но в итоге всё получилось.
3) Большие продуктовые компании (не аутсорсинг и аутстафинг), где давно осознали пользу юнит-тестов и вообще автоматизированной пирамиды тестирования и где наличие юнит-тестов обязательное требование закрытия задачи. Тут уже сами лиды и рукодители нередко будут тебя просить попробовать TDD.
Поэтому рецепт такой — продать сначала юнит-тесты и рефакторинг. А до самого TDD останется небольшой шажок, где нужно будет объяснить, что вместо того, чтобы сначала отлаживать и тестировать код руками, а потом еще и писать юнит тесты, которые не дадут обратной связи (т.к. код уже оттестирован руками), давайте сначала напишем юнит-тесты, и тогда сэкономим на отладке и ручном тестировании — т.е. в итоге будет быстрее и возможно даже качественнее.
Я бы топил за то, что на средней и особенно долгой дистанции с юнит-тестами быстрее, а TDD это практически единственный способ эффективно писать юнит-тесты.
DP>Так TDD применяется к юнит, РЕСТ АПИ и прочим подобным тестам. Чтобы их применяли к UI тестам – ни разу не слышал. А не применяют их там по озвученным тобою же причинам.
Насколько я понял, имелись в виду интерфейсы между компонентами, чтобы можно было подменять зависимости и делать чистые изолированные юнит-тесты.
В реальности даже не совсем идеальные юнит-тесты принесут пользу, так же можно по мере написания тестов на легаси вводить интерфейсы или другие способы подмены зависимостей.
Но в это-то и раскрывается еще один плюс TDD — когда пишешь код, сразу думаешь как его тестировать.
Здравствуйте, Nnova, Вы писали:
N>ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Ты же имеешь в виду интерфейсы тестируемых классов?
Я не практикую TDD полностью, чтобы всегда вот писать тесты до реализации функционала. Пишу как удобно — бывает пишу до, бывает после, бывает вообще не пишу юнит-тесты.
Тем не менее часто — да, начинаю писать тесты в начале, еще до реализации функционала. И тогда процесс такой:
1. Прикидываю в уме общий план как будет выглядеть решение, и примерные интерфейсы классов которые нужны при этом.
2. Накидываю интерфейсы классов
3. Пишу тесты, какие придумаю на этот момент
4. В процессе написания тестов, уже часто приходят мысли что "а вот неудобно же такое взаимодействие", и уточняю интерфейсы классов, дополняю тесты.
5. После нескольких итераций пунктов 3-4 интерфейсы исходного решения иногда заметно отличаются от исходных — а я еще и функционал фактически не писал
6. Начинаю делать функционал, в процессе иногда приходят мысли что надо добавить или исправить в тестах, повторяю с пункта 3.
7. А иногда и выясняется, что начальная структура была проблемной для реализации и приходится менять интерфейсы, взаимодействия классов и тесты. Ну бывает, не повезло.
то есть, если пишу тесты "до", то это не значит что весь их набор будет сразу. Часть дописывается и во время реализации и после.
Большой бонус — если у тебя есть уже хоть какие-то тесты к началу реализации функционала, то у тебя сразу есть средство для быстрого запуска отладки сразу твоего реализуемого функционала, без запуска всей системы целиком (что может быть очень трудоемко, а иногда вообще невозможно локально).
Здравствуйте, Nnova, Вы писали:
N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Я пишу тесты для кода, который я пишу. Проблем особых у меня не было. Начинаешь со "скелета", потом тест, потом реализация. Надо поменять код — ну значит меняешь и тест и код. Работы чуть больше с одной стороны, но в то же время чуть меньше в том плане, что ты в своём коде уже уверен, т.к. он не только компилируется, но и на самом деле хотя бы немного работает.
Другие пишут тесты из-под палки или вообще не пишут. Ну я не заставляю особо, у нас коммунизм, хоть как-то код пишется и то слава богу. Но на мой взгляд сильная команда тестами код должна покрывать, без фанатизма, но хотя бы 100% покрытие должно быть.
Здравствуйте, Nnova, Вы писали:
N>Последние лет 10 разработка с написанием тестов наперёд является сильно модной фишкой, многие компании хвастаются ей и говорят какой у них крутой процесс разработки, однако во всех местах что я работал — ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки
А мы о каком языке говорим?
В java и C# и Python редко увидишь TDD:
1) там большая часть кода просто не твоя, работает в сложном окуржении и воспроизведение окружения зачастую сложнее, чем само написание кода (пример работа с БД).
2) единица тестирования в них это класс, у классов в прикладных приложениях постоянно меняется интерфейс (рефакторинг), а тест и класс написаны в разных файлах. Это становится неудобно.
3) В таких проектах редко пишется код, который заранее понятно как должен работать. Весь такой код прописан в библиотеках. Для библиотек конечно TDD и юнет-тестирование оправданы, для конечных приложений не очень.
В rust или zig тесты являются частью исходного кода того модуля, где написаны и тестируют отдельные функции. Там TDD используется практически всегда. Ты просто пишешь функцию и делаешь тест с примером её использования. Модули целиком тестируются редко. По сути получается перманентное TDD без юнит-тестирования.
Про JS не скажу, там более простое окружение чем в бекенде, иногда заморачиваются воссоздавая его для тестов.
N>Есть тут те, кто реально юзает TDD на коммерческих проектах? N>Каким образом смогли ее внедрить?
Прям TDD не видел ни разу для конечных приложений на мейнстримных языках.
Здравствуйте, Nnova, Вы писали:
N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Тесты должны быть. А вот TDD (т.е. тесты до кода) применять не обязательно.
Если пилишь фичу, то удобнее сначала написать код (часть), и после этого уже тест. Потом накидываешь дополнительный тестовые кейсы, и по ним еще дописываешь код.
Если фиксится баг, то обычно удобнее наоборот — добавить тест кейс к имеющимся, и потом уже исправить код.
Здравствуйте, Быдлокодер, Вы писали:
Б>3) Большие продуктовые компании (не аутсорсинг и аутстафинг), где давно осознали пользу юнит-тестов и вообще автоматизированной пирамиды тестирования и где наличие юнит-тестов обязательное требование закрытия задачи. Тут уже сами лиды и рукодители нередко будут тебя просить попробовать TDD.
Б>Поэтому рецепт такой — продать сначала юнит-тесты и рефакторинг. А до самого TDD останется небольшой шажок, где нужно будет объяснить, что вместо того, чтобы сначала отлаживать и тестировать код руками, а потом еще и писать юнит тесты, которые не дадут обратной связи (т.к. код уже оттестирован руками), давайте сначала напишем юнит-тесты, и тогда сэкономим на отладке и ручном тестировании — т.е. в итоге будет быстрее и возможно даже качественнее.
Б>Я бы топил за то, что на средней и особенно долгой дистанции с юнит-тестами быстрее, а TDD это практически единственный способ эффективно писать юнит-тесты.
В одном небольшом проекте, как раз на аутсорсе, внедрял TDD, необходимость которого была вызвана misscomunication между аналитиком и разработчиками. На ручных интеграционных тестах выявили ошибки в имплементации. Заодно и рефакторинг провели.
Здравствуйте, Nnova, Вы писали:
N>Последние лет 10 разработка с написанием тестов наперёд является сильно модной фишкой, многие компании хвастаются ей и говорят какой у них крутой процесс разработки, однако во всех местах что я работал — ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Лет 20 уже по моему.
У нас не TDD к сожалению, но вот вчера дополнил тест новыми проверками и обнаружил два бага, один из них правда оказался новой фичей о которой меня не проинформировали. Так что польза есть. Вообще размер пользы зависит от контекста в котором используются тесты, если у вас разработка не ориентирована на тесты, то пользы будет не очень много.
Процесс (роль).
1) Разработка через моделирование (бизнес аналитик)
2) Разработка через требования (системный аналитик)
3) Разработка через проектирование (архитектор)
4) Разработка через кодирование (кодировщик)
5) Разработка через тестирование (тестировщик)
6) Разработка через отладку (отладчик)
7) Разработка через документирование (документовед)
8) Разработка через развёртывание (мейнтейнер)
9) Разработка через сопровождение (поддержка)
Я читал книжки про TDD и главная проблема в том, что у меня все другие процессы отстают от кодирования. Так как же авторы внедрили эти методики у себя и помогли перейти другим?
Всё просто, переходите в мой телеграмм канал и узнаете. Ладно это шутка.
На самом деле все, и авторы книг, и те кто в них признавался как они перешли на TDD, делали одно и тоже.
Они программировали десятилетиями в жёстком режиме и однажды им хватило умений поменять кодинг и тесты местами.
Достигнув вершины кодинга и дописывая тесты для каждого алгоритма в конце концов сможешь применить TDD.
Основа в том, чтобы сначала стать продвинутым кодером. А потом уже и продвинутым тестировщиком.
Здравствуйте, Nnova, Вы писали:
N>Последние лет 10 разработка с написанием тестов наперёд является сильно модной фишкой,
10? Отстаёте. 10 лет это как она уже растворяется, а "сильно модной" она была в 2005-2010.
N> многие компании хвастаются ей и говорят какой у них крутой процесс разработки, однако во всех местах что я работал — ни в одном TDD на реальных проектах не применялась по очевидным причинам — для них надо иметь уже проработанные интерфейсы, а их конечно же нет т.к. они "затвердевают" только в процессе самой разработки
Именно. Исключения подтверждают общность правила: обратное можно получить только там, где новой разработки ещё просто нет.
N>Есть тут те, кто реально юзает TDD на коммерческих проектах? Каким образом смогли ее внедрить?
Мой ответ: нахрен надо. TDD в чистом абсолютном виде нежизнеспособна, и обсуждать её такую просто нет смысла.
То, что имеет смысл обсуждать, это
1) Какие реальные формы разработки с тестированием должны использоваться при грамотном администрировании,
и
2) Как симулировать TDD, если его навязывают.
Если чуть шире, все модные тенденции последних 20-30 лет это инфоцыганство попыткой создания псевдо-soft-skills на базе hard-skills там, где люди не в состоянии сделать первых честным путём. Это и TDD, и SOLID, и паттерны GoF. Цель в принципе честная, если учивать, насколько разработка софта превратилась в такое же инвесторское дерьмо, как и любая прочая деятельность, но методы — нет.
Здравствуйте, B-52, Вы писали:
B5>В одном небольшом проекте, как раз на аутсорсе, внедрял TDD, необходимость которого была вызвана misscomunication между аналитиком и разработчиками. На ручных интеграционных тестах выявили ошибки в имплементации. Заодно и рефакторинг провели.
Здравствуйте, пффф, Вы писали:
vsb>>Но на мой взгляд сильная команда тестами код должна покрывать, без фанатизма, но хотя бы 100% покрытие должно быть.
П>Но 146% покрытие лучше
Иногда и 146 не дает ничего
Правильные ассершны ключевой момент без них покрытие мало что дает.
Покрытие легко измерить в остальном это хреновая метрика.
Mutation testing неплохо показывает в плане проверки "реального" покрытия но довольно таки дорого обходится
Здравствуйте, netch80, Вы писали:
N> Это и TDD, и SOLID, и паттерны GoF. Цель в принципе честная, если учивать, насколько разработка софта превратилась в такое же инвесторское дерьмо, как и любая прочая деятельность, но методы — нет.
Что не так с SOLID и GoF/GRASP?
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, netch80, Вы писали:
N>> Это и TDD, и SOLID, и паттерны GoF. Цель в принципе честная, если учивать, насколько разработка софта превратилась в такое же инвесторское дерьмо, как и любая прочая деятельность, но методы — нет. K>Что не так с SOLID и GoF/GRASP?
А вот не надо объединять, про GRASP я как раз ничего не говорил, он достаточно разумен.
SOLID — из всех возможных дохрена принципов выбраны конкретные 5 ради красивой аббревиатуры.
GoF — из реально больше сотни паттернов всех видов выбраны конкретные 23, причём отбор очень странный. Например, Builder у них это external builder. Я его видел в разы реже, чем builder context или internal builder. Prototype ни разу не встречал. Singleton есть, а parametrized singleton нет, хотя часто встречается. Зато нету автоматов в целом, хотя это фундамент более важный, чем какое-то Memento. И вообще, книге 30 лет исполнилось, первое издание даже до рождения Java(!), пора пересматривать актуальность в целом.
А вот GRASP — хорошая стартовая база для анализа и синтеза (и, повторюсь, не такая бессмысленная свалка ради красивого звука, как SOLID, хотя делает то же и лучше).
Здравствуйте, netch80, Вы писали:
N>GoF — из реально больше сотни паттернов всех видов выбраны конкретные 23, причём отбор очень странный. Например, Builder у них это external builder. Я его видел в разы реже, чем builder context или internal builder. Prototype ни разу не встречал. Singleton есть, а parametrized singleton нет, хотя часто встречается. Зато нету автоматов в целом, хотя это фундамент более важный, чем какое-то Memento. И вообще, книге 30 лет исполнилось, первое издание даже до рождения Java(!), пора пересматривать актуальность в целом.
Что-то не слышал про builder context, это откуда? Так-то да, многие вещи требуют пересмотра. Тот же синглтон теперь не совсем хорошее решение во многих случаях.
N>А вот GRASP — хорошая стартовая база для анализа и синтеза (и, повторюсь, не такая бессмысленная свалка ради красивого звука, как SOLID, хотя делает то же и лучше).
Не понимаю, чем тебе так SOLID не угодил? Он неплохо работает если не рассматривать его как серебряную пулю.
Здравствуйте, Kernan, Вы писали:
N>>GoF — из реально больше сотни паттернов всех видов выбраны конкретные 23, причём отбор очень странный. Например, Builder у них это external builder. Я его видел в разы реже, чем builder context или internal builder. Prototype ни разу не встречал. Singleton есть, а parametrized singleton нет, хотя часто встречается. Зато нету автоматов в целом, хотя это фундамент более важный, чем какое-то Memento. И вообще, книге 30 лет исполнилось, первое издание даже до рождения Java(!), пора пересматривать актуальность в целом. K>Что-то не слышал про builder context, это откуда?
У меня нет легкодоступных примеров того же для C++ или Java, но встречал таких.
K> Так-то да, многие вещи требуют пересмотра. Тот же синглтон теперь не совсем хорошее решение во многих случаях.
N>>А вот GRASP — хорошая стартовая база для анализа и синтеза (и, повторюсь, не такая бессмысленная свалка ради красивого звука, как SOLID, хотя делает то же и лучше). K>Не понимаю, чем тебе так SOLID не угодил? Он неплохо работает если не рассматривать его как серебряную пулю.
Именно что он создан как серебряная пуля и подаётся точно так же. И те, кто его любят поминать по каждому чиху, не замечают уже остальных не менее важных вещей.
При этом сам SOLID с одной стороны слишком абстрактен, с другой — слишком конкретен.
SRP это формулировка вообще ни о чём по сравнению с GRASPʼовскими Information Expert и Low Coupling / High Cohesion, которые дают ≈90% того, что разумный человек понимает под SRP.
Open/Closed реально означает "не меняйте публичные контракты, замучаетесь вычищать хвосты".
LSP должен говорить о стабильности контрактов в принципе, но только явно опубликованных.
IOC и DI это специфика, пригодная только для одного конкретного типа организации кода.
В сумме, годится только для контекстов типа Java EE, для остальных требует пересмотра.
В такой компании долго не проработал, что-то около 9 месяцев, поэтому не могу сказать был бы этот способ жизнеспособен на дистанции. 
