Comments 72
Создать сложное ПО, делающее сложные вещи - просто. А вот создать простое ПО, делающие сложные вещи - сложно.
"Это письмо получилось таким длинным потому, что у меня не было времени написать его короче" (с). Паскаль
Поддерживаю. Не уверен, что часто встречаю разработчиков, которые намеренно пытаются где-то использовать "рефлексию и ... какие-то безумно сложные вещи". Проблема скорее в том, что для того, чтобы получилось просто, надо приложить больше усилий.
Ну и пример с Wordpress как-то мимо кассы. Например, за интернет-магазины на Wordpress надо отлучать от профессии. Есть подозрение, что автор - индус.
Дешёвые программисты - причина сложности и дороговизны ПО.
Странно, что вы не затронули тему микросервисов, которые не нужны в 95% случаев.
Это ещё ничего, вот зоопарк методологий управления и планирования - вот где зоопарк, треш, угар и содомия
... ты читаешь рекомендованные многими книги, такие как “Чистый код”, “Рефакторинг” и т.д.
Хотя ты ясно видишь преимущества некоторых из этих техник, ты все еще не очень уверен в некоторых из них.
...
Однако, всему есть предел, и однажды ты говоришь, “мне не нравятся некоторые из этих практик”.
если провести аналогию с физикой:
... ты читаешь рекомендованные многими книги, такие как что-то про теорию относительности, дуализм, энтропию,... и т.д.
Хотя ты ясно видишь преимущества некоторых из этих техник (теорий, подходов,...), ты все еще не очень уверен в некоторых из них.
...
Однако, всему есть предел, и однажды ты говоришь, “мне не нравятся некоторые из этих практик”.
Интересно какой процент инженеров, которые решают задачи связанные с физикой (каким-то образом, двигатели внутреннего сгорания, например, это вполе себе с физикой связанное решение) хорошо разбираются в теорию относительности, корпоскулярно-волновом дуализме, сохранения энтропии и т.д. и т. п.?
Тем не менее, как я уже сказал ранее, мой стиль следования TDD мне нравится больше. И мне не надо никого ни в чем убеждать. Так что все в порядке.
Зачем вообще тогда пытаться подгонять свой стиль под TDD? Да, по ТDD нужно сначала писать тесты. Мне например это не нравится и поэтому я не использую TDD, не вижу тут совершенно никакой проблемы. Никто ж не запрещает писать тесты вне TDD.
Я много раз пытался полюбить эти архитектурные стили. Но я так и не увидел от них никакой пользы.
Потому что архитектурные стили обычно начинают показывать эффективность на реально больших проектах. Таких в целом не так уж и много. А с текущей тенденцией к разделению логики (микросервисы, лямбды, и т.д.) таких ситуаций еще меньше. Главное разделить логику, согласовать апишку, а дальше внутри проекта можно сделать максимально просто, так как там никакой сложности и нет.
Скажу коротко и просто:
Ценность или ее отсутствие того или иного стиля легче всего понять, когда надо вносить изменения.
Что в частности говорит о том, что если вносить изменения не требуется, то - можно меньше париться
Множество тестов можно вообще не писать, а их работу переложить на систему типов и тайпчекер (который справится намного лучше, чем прораммист). Рекомендую почитать "parse, don't validate"
Извини пожалуйста, а какие плюсы ты увидел в TDD?
Там же когда читать начинаешь, сначала думаешь: "гыгы, сказочник", потом " Мож и не надо легализовывать ничего", а потом "нужно сжечь кандома, пока это какой нить хирый мозгом менеджер не прочитал, и не пытался реализовать"!
Карго культ заканчивается там, где на кону появляются деньги.
Немного странный посыл по поводу TDD, как будто сильно припекло от кого-то. Просто не называйте "сначала код, потом тесты" TDD, и ни у кого не должно возникнуть вопросов. И не общайтесь с неадекватами ;-)
Все эти паттерны и методологии очень полезны, когда сам не чувствуешь программирование и не понимаешь его до конца. Оттуда и лишние слои абстракции, лишние действия и т.д. - человек просто пытается из заученных вещей составить программу. Я не говорю, что всё это не нужно, ведь это необходимая база. Тут, как в кулинарии: если ты не умеешь готовить, просто бери рецепт и следуй ему, а хороший повар помнит тысячи рецептов, но в то же время может не следовать ни одному из них и приготовить шедевр.
Именно так - методологии, это всего лишь заучивание практик других людей. Необходимый этап обучения, не более.
А уж методологии управления коллективом разработчиков, вроде скрама - вообще выглядят как инструкции по управления абсолютно расхлябанными и недисциплинированными людьми, которым если каждое утро не напомнить, какой задачей они заняты - так и не вспомнят.
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
(В 100500-й раз!) TDD — не про тесты!
Когда я реализую некую функциональность, я читаю задачу, анализирую ее, глубоко продумываю, как я собираюсь её реализовывать и затем начинаю писать код.
Как происходит анализ? Как происходит продумывание? На сколько глубоко?
…Там ещё много вопросов про то, как именно происходит "превращение" задачи в исходный код. И все эти вопросы увязаны в большой клубок, который и называют сложностью разработки ПО.
TDD предлагает систему методов, позволяющих надёжно находить ответы на все озвученые выше и некоторые другие вопросы из этого клубка. TDD — это методология, то есть система методов. И написание "теста" до кода — один изз методов в этой системе. Но не единственный. И только в сочетании с другими методами получается система — нечто большее, чем "сумма" элементов. Можно использовать Test-First отдельно от другим методов. Но это не даст всех преимуществ TDD. Можно исключить Test-First из TDD. И это тоже разрушит систему и снизит её эффективность.
Если кто-то знает другие, лучшие способы отвечать на эти вопросы — флаг ему в руки! TDD ему не нужно. Только вот почему-то очень редко, кто делится своими знаниями. Вы знаете метод "превращения" требований в реализующий их код? Поделитесь, пожалуйста!
А то вот я практикую TDD уже скоро 20 лет. Не потому что фанат. А просто потому, что те способы, которые я знал и использовал до этого работали гораздо хуже. И до сих пор работают значительно хуже — я вынужден к ним время от времени возвращаться, так что знаю. И новых, которые бы давали лучший вариант, за это время не нашёл.
У вас получается лучше без TDD? Тогда не тратьте время на критику, лучше расскажите подробнее, как надо!
TDD — это методология, то есть система методов.
...
Можно исключить Test-First из TDD. И это тоже разрушит систему и снизит её эффективность.
По моему главное в разработке софта это то что тот кто написал программу или алгоритм или какое-то взаимодействие, конфигурацию, ... что угодно что может быть написано и по этому написанному будет работать машина (вычислительная, а может стиральная в составе которой все равно есть вычислительная, например), так вот тот кто это написал должен знать как это проверить, в том смысле что он должен быть способен объяснить и даже доказать и показать что задача предметной области выполняется с помощью этой писанины(алгоритма и чего угодно) и значит алгоритм написан правильно - он работает.
А то есть такие деятели которые говорят вот я тут ВСЕ(!) написал осталась сущая ерунда проверить то что я написал. Проверять это не моя работа. Пусть тестеры проверяют.
Только написать проверочный код в общем случае намного сложнее чем просто рабочий код. Это из той же оперы что и проверочное и измерительное оборудование-железо к нему требования на порядок выше, поэтому оно на порядок сложнее и дороже.
Потом если кто-то не знает как проверить то что он написал, возникает вопрос, а понимает ли он то что он написал, понимает ли задачу предметной области решение которой он собрался перепоручить машине.
Я не очень понял, как эти рассуждения — во многом правильные — связаны с TDD?
Да, хотелось бы, чтобы всё программное обеспечение было правильным. Да, тестирование — единственный на сегодняшний день практичный способ хоть как-то обеспечить это. Да, вероятно (и я с этим согласен) TDD делает код "более тестируемым".
Но основная цель TDD состоит не в том, чтобы дать возможность тестировать код. Цель — дать возможность этот код написать.
Но нельзя и проводить аналогию между TDD и описанными "деятелями", так как TDD — пусть и в качестве "побочного эффекта", но — поддерживает тестирование. Просто это не случайная побочка, а следствие какой-то закономерности, связи между спецификацией требований, их программной реализацией и проверкой соответствия полученной программной реализации исходным требованиям.
(…Тут Остапа меня чуть было не понесло. Но я вовремя остановился и дальнейшие скачки своей мысли приберёг на будущее :) )
Но нельзя и проводить аналогию между TDD и описанными "деятелями", так как TDD — пусть и в качестве "побочного эффекта", но — поддерживает тестирование.
где ж вы увидели такую аналогию-то? TDD по моему это как раз метод избавиться на корню с такими деятелями, мне так кажется! Чтобы даже не заикались что тестировать будет кто-то другой и когда-то потом. Ну и то что тестирование ставится во главу процесса и в первую очередь задает ту самую значимость тестирования про которую я написал ссылаясь на аналогию со значимостью измерительного оборудования.
где ж вы увидели такую аналогию-то?
Я её не увидел. Я как раз написал, что её нет. Возможно, перемудрил с формулировкой. Всего-то хотел сказать, что TDD — это про разработку, а не про тестирование. И тестировщиков напрямую не воспитывает. Просто позволяет писать код, про который можно как раз чаще говорить
вот я тут ВСЕ(!) написал осталась сущая ерунда проверить то что я написал. Проверять это не моя работа. Пусть тестеры проверяют.
Задача разработчика — написать код, который соответствует требованиям.
Задача тестировщика — убедить (себя, а затем и других), что этот код действительно соответствует требованиям.
Так что с утверждением
TDD по моему это как раз метод избавиться на корню с такими деятелями, мне так кажется!
я в корне не согласен. Хороший программист не участвует в тестировании. Но пишет код, который тестировать проще и приятнее. И когда (не если — так не бывает) найдутся баги, фиксит их быстро и эффективно. TDD способствует и в написании, и в сопровождении. Но каждый должен заниматься своим делом.
Моя мысль стала понятнее или ещё больше запутал? :)
TDD создана для разработчика. Разработчик должен разрабатывать, а не тестировать. Но если (как в случае с TDD) помочь в тестировании ничего не стоит, то почему бы и нет.
Моя мысль стала понятнее или ещё больше запутал? :)
TDD создана для разработчика. Разработчик должен разрабатывать, а не тестировать.
Я понял что вы почему то хотите чтобы все было или перпендикулярно или параллельно. Но кривые к сожалению в реальной жизни тоже присутствуют, например как вы ответите на такой вопрос:
а разработка тестов это тестирование или разработка?
Я понял что вы почему то хотите чтобы все было или перпендикулярно или параллельно
Нет, вы не поняли.
а разработка тестов это тестирование или разработка?
Вы определитесь с тем, что такое тест — тогда я смогу ответить.
Точнее, тогда я смогу ответить здесь — кратко. И в любом случае я отвечу — но подробно, но не здесь.
Ну и то что тестирование ставится во главу процесса и в первую очередь задает ту самую значимость тестирования про которую я написал ссылаясь на аналогию со значимостью измерительного оборудования.
И ещё раз — не устану повторять :) Если речь про TDD, то там тестирование не ставится во главу процесса. Написание теста — это ещё не тестирование. В TDD тест это (1) спецификация, (2) фронт работ (чтобы разраб не уходил в фантазии — по сути, YAGNI), (3) дизайн в коде, (4)… — там ещё "функции", но тестирования как такового среди них нет.
Но мне все таки кажется что тесты не обязательно надо писать до создания рабочего кода. Главное, по моему, нельзя считать код написанным (задачу решенной, функцию реализованной) пока нет теста который демонстрирует работу этого кода, при таком подходе это все равно можно определить как TDD, по моему. Если наличие теста определяет завершенность работы над функциональностью, процесс разработки управляется тестированием, неважно когда тест появился до или после, главное что без него работа не считается завершенной.
Главное, по моему, нельзя считать код написанным (задачу решенной, функцию реализованной) пока нет теста который демонстрирует работу этого кода, при таком подходе это все равно можно определить как TDD, по моему
А разве сам TDD не требует чтобы сначала были написаны тесты: https://martinfowler.com/bliki/TestDrivenDevelopment.html ?
я честно говоря теряюсь, пытаясь понять как ваш вопрос связан с тем что вы процитировали.
Может вы просто ссылкой хотели поделиться, за ссылку спасибо.
Очень просто. По ссылке описание TDD. В этом описании указано например вот такое:
Although these three steps, often summarized as Red - Green - Refactor, are the heart of the process, there's also a vital initial step where we write out a list of test cases first.
То есть важно не только чтобы тесты были, но и чтобы сначала были написаны тесты. Иначе уже получается не TDD.
У вас есть какое-то другое определение TDD?
На сколько я это понимаю у меня оно не другое оно более обобщенное что ли. Потому что даже по вашей ссылке там в начале просто список тестов, я так понимаю примерный-предпологаемый, который в процессе работы уточняется и дополняется, то есть тесты не появляются раньше кода - это сложный процесс - некоторые тесты могут быть написаны раньше, а некоторые могут быть закончены или даже придуманы только по результатам работы с кодом. Там же написано: "Update list us we learn", на сколько я понимаю это значит что не все тесты мы обязаны написать сначала.
А вы как это понимаете?
Потому что даже по вашей ссылке там в начале просто список тестов, я так понимаю примерный-предпологаемый, который в процессе работы уточняется и дополняется
Да, но по моей ссылке написано что сначала пишешь тест, потом пишешь код который его проходит.
И это необходимое условие. И если сначала писать код а потом тесты к нему, то это уже не TDD а просто разработка с применением тестов.
некоторые тесты могут быть написаны раньше, а некоторые могут быть закончены или даже придуманы только по результатам работы с кодом
Но при этом тест, который проверяет какое-то конкретный кусок кода должен быть написан раньше этого кода. И если вы хотите менять какой-то кусок кода, то вы сначала пишите тест который будет проверять изменения.
Что ж непонятного?
Есть принцип: "вся функциональность должна быть покрыта автоматическими тестами". Например, этот принцип присутствует в eXtreme Programming.
Есть методология TDD, в которой написано чётко: "до написания кода, необходимо написать тест, который проверит, что данный код делает то, что требуется".
Если вы покрываете всю функциональность автоматическими тестами, это прекрасно! Но если вы не пишите тесты до кода, то вы не придерживаетесь TDD. Просто потому, что нарушаете необходимое условие. (Оно, кстати, не является достаточным.)
Но если вы не пишите тесты до кода, то вы не придерживаетесь TDD.
ну да, и трава должна быть зеленой, а если она желтая ее надо покрасить, примерно такая логика получается. Написано, исполняйте товарищ, не нарушайте необходимых условий.
Вас же никто не заставляет придерживаться TDD. Не хотите так не надо. Никто же не утверждает что без этого нормальный код не напишешь.
Но если вы хотите работать по TDD, то правила надо выполнять.
Но если вы хотите работать по TDD, то правила надо выполнять.
так почему же вы игнорируете правила, которые происходят из перехода: "Update list us we learn". Только вы можете правила определять?
Вы не замечаете, что вы утверждаете, что только ваше ограниченное в некотором смысле определение TDD истинно? То есть только вы знаете как оно правильно преобразуется в "правила"?
так почему же вы игнорируете правила
Эээ, какие правила я игнорирую? И где?
Только вы можете правила определять?
В данном случае их не можем определять ни я, ни вы. Они уже давно определены.
Вы не замечаете, что вы утверждаете, что только ваше ограниченное в некотором смысле определение TDD истинно?
Это не моё определение. Это общепринятое определение. Более того я даже специально спросил можете ли вы привести ваше.
Вопрос скорее в том зачем вы хотите называть ваш подход именно TDD? Какой в этом смысл? Просто хотите использовать модное слово?
Вопрос скорее в том зачем вы хотите называть ваш подход именно TDD? Какой в этом смысл? Просто хотите использовать модное слово?
Я хотел просто пояснить что не надо так буквально и формально воспринимать такую сложную концепцию, вы теряете ее смысл.
И да я с вами согласен, что-то увлекся обсуждением понимания модной абревиатуры, вполне можно обойтись и без нее.
Спасибо за дисскусию.
В принципе, всё стало ясно. Точнее, подозрения подтвердились.
Просто возьмите нормальную книгу по теме. Советую "Test-Driven Development by Example" Кента Бека (есть плохой, но русский перевод). И разберитесь, какой смысл в этот термин вложил автор. Если есть желание именно разобраться и понять идею и принципы, этой книги хватит за глаза. Дальше можно моки, BDD и т.д.
Если же просто почему-то нравится название "TDD" и хочется наполнить его собственным содержанием… извините, удачи желать не буду. Не одобряю. Подобного "добра" уже хватает. На столько хватает, что TDD, похоже, ожидает участь ООП (и, наверняка, многих других) по схеме
Гениальная идея —> Хайп —> Непонимание —> Извращение —> Визги ОНО НЕ РАБОТАЕТ!!!
В своей аргументации вы отталкиваетесь от очень распространенного заблуждения, что целью TDD является тестирование. Это абсолютно не соответствует действительности.
Как намекает название, методология Test Driven Development (разработка посредством тестов) имеет целью упорядочивание процесса разработки, и тесты в ней применяются лишь как средство. Тест в ней является не средством тестирования, а способом соотнести разрабатываемый функционал и список требований к нему. В TDD вы пишете тест, чтобы быть уверенным, чтобы тот код, который вы собираетесь написать, закрывает определенное требование из спецификации. Именно поэтому тест нужно писать до начала кодирования, а вовсе не потому, что после его завершения у вас будет соблазн забить на тесты и от этого пострадает тестовое покрытие.
То, что в результате разработки по TDD увеличивается тестовое покрытие, - это всего лишь побочный эффект. И если все получившиеся тесты по окончании разработки просто взять и удалить, TDD все равно выполнит свою основную функцию - систематизацию процесса разработки. (Другое дело, что мы этого не делаем, потому что расширение тестового покрытия - это положительный, полезный побочный эффект.)
В своей аргументации вы отталкиваетесь от очень распространенного заблуждения, что целью TDD является тестирование.
да нет, с чего вы взяли? я как раз пытался рассмотреть методологию или даже способ организации разработки в более широком смысле, вроде как.
Вот вы отталкиваетесь в ваших рассуждениях:
В TDD вы пишете тест, чтобы быть уверенным, чтобы тот код, который вы собираетесь написать, закрывает определенное требование из спецификации.
что требования всегда полны и коректно написаны, по моему, но на практике так просто не бывает. Вроде как требования это тоже результат разработки в какой-то степени, по крайней мере мне так кажется. Я собственно пытался развивать мысль в этом направлении, но это направление похоже никому не интересно.
Вот вы отталкиваетесь в ваших рассуждениях /…/ что требования всегда полны и коректно написаны, по моему, но на практике так просто не бывает.
Не хочу отвечать за автора того сообщения, но правильно понимание TDD отталкивается от того, что требования должны быть специфицированы — т.е. корректно описаны — до начала кодирования. Кто это сделает — аналитик, разработчик, тестировщик или (в идеале) все вместе — вопрос вне рамок TDD.
Вроде как требования это тоже результат разработки в какой-то степени, по крайней мере мне так кажется. Я собственно пытался развивать мысль в этом направлении, но это направление похоже никому не интересно.
Очень даже интересно. Только это уже не про TDD. "Вокруг и около" TDD — да.
И, прежде чем развивать что-то, желательно сначала узнать и понять это что-то. Тогда и лишней работы меньше будет, и вас поймут быстрее, и ваши мысли оценят по достоинству.
И, если что, я считаю, что дискуссия была очень полезной. Только надо общий язык выработать, чтобы про одно и то же разными словами не говорить и, что, вероятно, ещё хуже, разные вещи одинаковыми словами не называть.
но правильно понимание TDD отталкивается от того, что требования должны быть специфицированы — т.е. корректно описаны — до начала кодирования.
Что и требовалось выяснить, те кто пропагандирует TDD свято верят что требования могут быть корректно описаны (абсолютно и совершенно) до начала кодирования, но мой практический опыт, например, показывает что так не бывает (тоже абсолютно и совершенно) .
те кто пропагандирует TDD свято верят что требования могут быть корректно описаны (абсолютно и совершенно) до начала кодирования
Ну кто в такое вообще может верить? :) Вы же в любом случае (даже без TDD), как минимум сперва у себя в голове продумаете и уточните эти требования (ведь прежде, чем писать рабочий код, нужно думать, что писать). TDD просто предлагает прописывать их сперва в тесте, а потом уже писать рабочий код. И, вроде бы, никто не утверждает, что эти требования должны сразу быть полны и конечны. Никто не призывает сперва прописывать полную спецификацию.
А те, кто не пропагандирует TDD, верят, что можно сделать что-то, не понимая, что нужно сделать? ;D
Ну, прошу вас, попробуйте уже выйти из режима "чукча не читатель" и таки почитайте уже про TDD. Это дело люди не тупее нас с вами придумали.
Они понимали, что программная система — сложная. И что требования к программной системе — тоже сложная штука. И они знали, что человечество придумало хороший способ "борьбы" со сложностью — делить сложные вещи на более простые. Как сейчас модно говорить "есть слона по кусочкам". И предложили делать именно так, и с реализацией в целом, и (sic!) с требованиями. Потому как они-то понимали, что без понимания требований не будет и реализации. Точнее, может и будет. Но не та, которая нужна.
Именно поэтому итерация в TDD начинается с того, что придумывается сценарий, который описывает, как соответствующая предъявляемым требованиям система должна повести себя в этой конкретной ситуации. Понимаете "фишку"? Из огро-о-омной такой непонятной кучи чаще всего произвольным образом обобщённых "требований" выводим (дедукцией) один ма-а-аленький такой, очень конкретный, а потом гораздо более простой и понятный кусочек — пример. Это и есть способ уточнить — т.е. специфицировать — требования. Спецификация на примере.
Такой конкретный и ограниченный пример гораздо проще понять. Его не так сложно оценить на предмет соответствия требованиям. Его и реализовать проще. Проще — значит и быстрее. А понимаете, зачем нужно быстрее? Чтобы можно было быстрее показать эту самую систему и получить обратную связь: а правильно ли мы поняли требования? В нужном направлении мы двигаемся? Требования ведь не только сложны, они ещё и меняться любят.
Так что не придумывайте — про "абсолютно" и "совершенно" речи не было. Инженерия, если вы вдруг не в курсе, такого вообще не приемлет. Всё ограничивается словом "достаточно". Требования должны быть достаточно хорошо специфицированы, чтобы программная система могла в достаточной мере им соответствовать.
И идея TDD заключается в том, чтобы приближаться к искомому результату постепенно — (в том числе и) для того, чтобы не было необходимости сразу "абсолютно и совершенно" точно формулировать требования, сразу делать "абсолютный и совершенный" дизайнить, сразу "абсолютно и совершенно" правильно кодировать.
и таки почитайте уже про TDD. Это дело люди не тупее нас с вами придумали.
вы почему то игнорируете то, что я не спорю с тем что люди это придумали правильно, я просто пытался обратить внимание, что на практике возможны нюансы и исключения. Нет в мире ничего универсального, любая методика имеет область своего применения и не терпит формального исполнения в любых условиях.
рассмотреть методологию или даже способ организации разработки в более широком смысле
А TDD — это про разработку в узком смысле как раз: про "программирование", "кодирование", про реализацию требований. Не про весь цикл разработки.
Создавать отдельные модели запроса и ответа для каждого случая использования.
Под моделями запроса и ответа подразумеваются DTO?
Почти 15 лет в разработке, тесты не писал ни разу, только заглушку для тестового пайплайна в гите. Автотесты пишут автотестеры, нагрузочные тесты пишут нагрузочники, остальное тестят на ручнике мануальщики. Админы ставят софт, настраивают вм, девопсы занимаются деплоем кода на то, что настроили админы, архитекторы пишут архитектурные документы и проектируют, запросы в БД пишут разработчики БД и снимают метрики производительности запроса, администраторы БД настраивают и мониторят БД, безопасники проверяют на уязвимости то, что мы закинули в репозиторий, SRE настраивает красивые метрики и следит, чтоб если падало, то громко. И только на Хабре водятся мифические сеньоры-помидоры которые зачем-то делают всё это сами 😁
Если я на работе вдруг ударюсь головой и напишу тест, то концептуально это будет автотест, а для этого есть отдельная команда. Если я в тесте все взаимодействия с другими микросервисами замокаю, чтоб это не был автотест, то получится какое-то хаотичное формирование некоего json суррогата, которое ещё потом надо поддерживать. А дебажить и исправлять все равно будешь ровно столько же на интеграции.
Так а в TDD тоже тесты совсем не обязательно должен писать тот же человек, который потом пишет код.
Кстати, да — не помню, чтобы где-то говорилось о том, что создавать тест и реализовывать его должен один и тот же человек.
Но, по-моему, это потому, что просто не приходило в голову уточнять. Всё указывает на то, что TDD задумывалась как индивидуальная практика (парное программирование, как ни странно, тоже отношу к индивидуальной практике).
Просто смысл TDD проявляется как раз в том, что Red-Green-Reafactor "пронизаны" единым замыслом. Создавая тест, разработчик закладывает дизайн, распределяя ответственность между разрабатываемой подсистемой и сотрудниками ("коллабораторами"). Если тот, кто реализует тест, не понимает или не разделяет эту точку зрения, ничего хорошего не получится.
я вот не соглашусь. На мой взгляд процесс в TDD как раз отлично делится на несколько людей. И на мой взгляд даже правильно было бы разделать написание тестов и кода между разными людьми.
Потому что если эти люди не разделяют одну точку зрения, то им придётся как.-то найти общий знаменатель. То есть уменьшается вероятность того что один разработчик что-то не так поймёт и поэтому начудит.
Потому что если эти люди не разделяют одну точку зрения, то им придётся как.-то найти общий знаменатель.
Вопрос не в том, чтобы найти "общий знаменатель" — это само собой разумеется внутри команды. Вопрос в том, где его искать и каким путём к нему приходить.
На мой взгляд процесс в TDD как раз отлично делится на несколько людей.
Делится как именно? Просто у меня для этой вашей фразы
на мой взгляд даже правильно было бы разделать написание тестов и кода
есть 3 возможных трактовки. Одна из них тривиальна и очевидна. Вторая приводит к нарушению если не "буквы", то духа "TDD". А вот третья — интересная, я как раз над этим вопросом сейчас работаю :)
Вопрос в том, где его искать и каким путём к нему приходить.
Давайте зайдём с другой стороны. Вот допустим у вас не TDD. Разработчик пишет код и потом QA его тестирует. Им нужно находить общий знаменатель? Если да то в чём разница?
Делится как именно?
Один человек отвечает за тесты, а другой за написание кода под эти тесты.
Разница примерно такая же, как между пассажиром, который нашёл "общий знаменатель" с водителем в виде конечного пункта и некоторых общих условий поездки (таких как стоимость, примерный маршрут и т.д.), и пассажиром, который ищет "общий знаменатель", указывая водителю, как он должен управлять автомобилем, как нажимать на педали, когда в какой ряд перестраиваться, где ускоряться. где тормозить, а то и вообще пытается схватить за руль и самостоятельно понажимать на педали.
Задачей программиста является реализация программы, соответствующей требованиям — аналогично тому, как водитель берёт на себя ответственность за то, чтобы довезти вас в нужную точку в соответствии с договорённостями.
TDD предлагает сначала выделить ебольшой "кусок" требований и зафиксировать его в виде сценария, описывающего, как — в соответствии с требованиями — программа должна себя вести в одном конкретном случае. Причём сценарий предлагается записать на языке программирования. А для этого в свою очередь нужно решить, какой объект будет отвечать за реализацию соответствующей функциональности, как этот объект будет получен или создан, какие сообщения будут ему отправлены, как проверить полученный результат (в классическом TDD) или с какими объектами и как он должен будет провзаимодействовать (в "TDD с моками" что примерно равно BDD). Другими словами — спроектировать.
И разница заключается в том, доверяете ли вы программисту на столько, что позволяете ему самостоятельно спроектировать решение поставленной задачи. Если да, то не хватайтесь за руль — вы только помешаете ему. А если нет, то о TDD нет и речи.
А вот если вы до того, как разработчик начнёт программировать (запустит итерацию TDD) соберёте вместе аналитка, который хорошо разбирается в требования, этого разработчика и QA, который впоследствии будет тестировать полученный код, то… но это будет уже совсем другая история.
Задачей программиста является реализация программы, соответствующей требованиям
Отлично. В чём проблема если соответствие требованиям проверяются в виде тестов? В чём проблема если тесты написаны раньше кода?
TDD предлагает сначала выделить ебольшой "кусок" требований и зафиксировать его в виде сценария, описывающего, как — в соответствии с требованиями — программа должна себя вести в одном конкретном случае
А когда вы тестируете программу, то это делать не нужно? Или у вас QA пишут тесты так чтобы они соответствовали написанному коду, а не требованиям в ТЗ?
. А для этого в свою очередь нужно решить, какой объект будет отвечать за реализацию соответствующей функциональности, как этот объект будет получен или создан
Ну да. Разрабатываем архитектуру, прикидыааем интерфейсы и потом каждый пишет свою часть. Один тесты, другой код.
Если в процессе замечаем что что-то пошло не так, то адаптрируем архитектуру и интерфейсы.
Ведь совсем не обязательно чтобы абсолютно все тесты были готовы до того как начнут писать какой-то код.
Не пойму, вы меня троллите?
В чём проблема если соответствие требованиям проверяются в виде тестов?
Ни в чём. В условиях отсутствия практической возможности доказывать правильность программ, я не знаю других способов проверки соответствия требованиям.
А когда вы тестируете программу, то это делать не нужно?
- Чтобы залить омывайку, вам придётся открыть капот.
- А чтобы уровень масла замерить, капот не придётся открывать?!
Я про тестирование в этом месте не говорил. Вообще. Я говорил про управляемую тестами разработку. Разработка (в узком смысле) и тестирование — разные активности. Хотя бы потому, что у них разные цели.
Разрабатываем архитектуру, прикидыааем интерфейсы и потом каждый пишет свою часть.
Пожалуйста, делайте как вам больше нравится. Только не обзывайте TDD то, что TDD не является.
Ведь совсем не обязательно чтобы абсолютно все тесты были готовы до того как начнут писать какой-то код.
Я вам больше скажу: если у вас все тесты готовы до того, как начнут писать код, то это будет не TDD.
Можно спросить: Вы с чем спорите-то? И зачем?
Просто напомню: вы предложили разделить написание тестов и их реализацию. Я спросил, что именно вы под этим подразумевали. И ещё хотел про опыт узнать.
Разработка (в узком смысле) и тестирование — разные активности.
У вас в обоих случаях будет разработка и тестирование. Поэтому мне интересно почему вы считаете что в одном случае людям нужно будет "находить общий знаменатель", а в другом нет.
Можно спросить: Вы с чем спорите-то?
С тем что "Всё указывает на то, что TDD задумывалась как индивидуальная практика"
И зачем?
Потому что не согласен с вашим утверждением.
И ещё хотел про опыт узнать.
Где-то с десяток проектов по TDD и из них условно говоря полтора когда тесты и код писали разные люди.
Где-то с десяток проектов по TDD и из них условно говоря полтора когда тесты и код писали разные люди.
Интересны, конечно, подробности. Судя по всему, тут речь идёт о применении "TDD" (что бы под этим ни подразумевалось) именно на командном уровне. Это очень интересный для меня вопрос.
почему вы считаете что в одном случае людям нужно будет "находить общий знаменатель", а в другом нет.
Никогда я так не считал! Вы, должно быть, неверно поняли :)
С тем что "Всё указывает на то, что TDD задумывалась как индивидуальная практика"
Признаюсь, с тех пор я изменил своё мнение. Я раньше как-то особо не задумывался над этим вопросом — ответ казался очевидным. Теперь, после раздумий, анализа собственной и чужой практики, более пристального изучения этого вопроса должен признать, что теперь я гораздо более уверен, что TDD — индивидуальная методология. Но это не исключает того, что часть составляющих её практик можно и даже нужно выводить на командный уровень. Возможно, это станет основой для какой-то командной методологии "в русле agile". Или уже стало? Например, что-то похожее есть в незаслуженно забытой eXtreme Programming. А ещё есть ATDD, Agile Acceptance Testing, Specification by Example…
Я собираюсь в ближайшее время изложить свои соображения по этому вопросу и обязательно поделиться ссылкой :)
В целом, у меня есть ощущение, граничащее с уверенностью, что мы говорим об одном и том же. Только вы более вольно трактуете TDD. Я же считаю, что это не очень хорошо. В ИТ уже очень много проблем, связанных с неверной трактовкой, искажением и незаслуженной дискредитацией хороших идей. Но про это я уже писал где-то в предыдущих комментариях. Вместо придания новых смыслов уже существующим концептам лучше придумать новый и объяснить, чем он лучше.
Спасибо за обсуждение, для меня было полезно. Со своей стороны предлагаю не терять контакт.
Интересны, конечно, подробности. Судя по всему, тут речь идёт о применении "TDD" (что бы под этим ни подразумевалось) именно на командном уровне.
Ну я если честно не особо знаю какие подробности вам интересны. "На командном уровне" было те самых полтора проекта. И примерно так как я описал: сначала прикинули архитектуру и нарисовали интерфейсы. Потом один человек готовил тесты под эти интерфейсы, а второй потом писал код.
Но да, это был более-менее "стандартный" проект. Никаких особых экспериментов, PoCов, прототипов.
Спасибо за обсуждение, для меня было полезно. Со своей стороны предлагаю не терять контакт.
Взаимно :)
Интересны, конечно, подробности. Судя по всему, тут речь идёт о применении "TDD" (что бы под этим ни подразумевалось) именно на командном уровне.
Ну я если честно не особо знаю какие подробности вам интересны. "На командном уровне" было те самых полтора проекта. И примерно так как я описал: сначала прикинули архитектуру и нарисовали интерфейсы. Потом один человек готовил тесты под эти интерфейсы, а второй потом писал код.
Но да, это был более-менее "стандартный" проект. Никаких особых экспериментов, PoCов, прототипов.
Спасибо за обсуждение, для меня было полезно. Со своей стороны предлагаю не терять контакт.
Взаимно :)
следуя TDD надо сначала писать тесты!
Вот пусть и пишут, им никто не запрещал. Пусть хоть на голове ходят, если это внезапно станет модно. Лично я сначала делаю анализ, дизайн, набрасываю скелет решения, а уж потом итеративно реализовываю его параллельно с тестами.
Вообще TDD -- это методология о том, как написать калькулятор. В реальной среде там возникает куча проблем, о которых постоянно спорят на форумах, такие как: излишняя фрагментация, множественное покрытие, идеализированное окружение, сконцентрированность на внутреннем дизайне вместо бизнес кейсов, общая сложность написания, etc.
Могу ли я сказать, что следую TDD
С другой стороны, почему вас так задевает, являетесь ли вы труЪ адептом TDD или нет? Хотите поговорить об этом? :)
Помню себя 15-20 лет назад, когда всеми силами пытался разобраться как "правильно" писать и огранизовывать код, всасывая всевозможные паттерны и концепты. На определенном этапе я понял, что объективно никакого "правильного" варианта не существует, а большинство идей и концептов -- это не более чем расхайпленное персональное мнение одного или нескольких уважаемых людей, которые последний раз бизнес код писали N-дцать лет назад. А не говорю, что не стоит знать и понимать эти идеи, я лишь призываю скептически к ним относится, в особенности когда они преподносятся как лекарство от всех болезней и диких зверей.
получать возможность тестировать логику с инфраструктурными компонентами, используя такие инструменты, как Testcontainers.
Именно. Все мокированные юниты -- это мусор, который мешает дальнейшей разработке и рефакторингу, и основной смысл которых -- это поднять метрику покрытия. Сегодня мы в основном пишем микросервисы, в которых API -- это фактическая бизнес-спецификация, которая должна быть покрыта тестами и выдерживать регрессии. И фрагментировать тестовое покрытие на более мелкие внутренние компоненты в большинстве случаев не имеет смысла.
Кто-то умный сказал: "простота - залог успеха", но он отнюдь не писал код
Разработка ПО действительно так сложна? Или это мы делаем ее такой?