Всякое бывает — скрининги всякие, особенно если доступ к чувствительным данным будет. Врядли будет большой проблемой, но может быть неприятно.

Другий спосіб трохи складніший — необхідно з контролера разом із даними передати в шаблон конфігурацію форми. А вже шаблонізатор, на основі переданої йому конфігурації, динамічно створює форму разом із даними. У наслідок цього можна повністю уникнути дублювання коду.

Втім у цього підходу є один маленький недолік — він порушує правила архітектурного шаблону MVC. Адже контролер не має ніякого відношення до форм, це юрисдикція вигляду (View), у нашому випадку шаблонізатора.

На самом деле правильный второй способ — и оптимальный в данном случае — иметь динамический view, т.е. генерировать на сервере (php, java, etc) или клиенте (react, angular, elm, etc) форму, куда потом развертывать модель.

Ваш третий вариант может теоретически иметь смысл только если вообще никакой возможности нету генерить view или использовать нормальные templating engines, да и то я бы лично еще подумал что лучше — немного простой повторяющейся разметки или жуткий зомбозавр xslt.

А почему для написания блек-бокс тестов нужно сначала выкосить юнит тесты? Предположим они действительно никому кроме автора не нужны — но ведь они проходят. И, возможно, автор зачем-то их писал — даже если ты не понял зачем. Чем они мешают?

Ну чисто формально для блек-бокс самих по себе — юниты выкашивать не обязательно, но они таки здорово мешают.

Во-первых мешают изменениям кода, поскольку сильно чувствительны к минимальным изменениям имплементации. Может где-то у кого-то и получается так писать по open/closed principle так. что реализация не меняется, но мне лично кажется что это больше сказки или очень нишевый контекст.

Во-вторых, редко когда было что-то полезное в сильно-моковых тестах, и исчезающе редко — это что-то должно тестироваться именно как white-box. По-этому вместо того, чтобы каждый раз разбираться имел ввиду что-то автор или нет — лучше один раз порефакторить эти тесты. Что можно — вынести на black-box или уровнями повыше. Что нельзя — то остается тут — но тогда уже понятно что это что-то очень низко уровненное. Часто (в моем контексте) тут остаются обработки каких-то исключительных ситуаций, которые муторно (если вообще возможно) воспроизвести более высокоуровневыми тестами.

Покрываешь нормальными блек-бокс тестами на нужных уровнях — из моего опыта покрытие чужого кода блек-бокс тестами это очень сложная и неблагодарная работа. Я вижу в ней смысл только если мы хотим изолировать какой-то модуль, переписать его с нуля, а старый — выбросить. И потом еще встанет вопрос хотим ли мы тратить время на поддержание этих блек-бокс тестов?

Да, не очень просто, особенно поначалу в кодобазе где «все замокать и забыть». Но в принципе с опытом — не смертельно, и в последние 5-10 лет появилось много инструментов и подходов, позволяющих построить относительно легко поддерживаемые реалистичные блек-бокс с базами и всем, гоняемыми на каждый коммит. Один докер чего стоит.

В целом, поддержка хорошо написаных блек-бокс тестов ИМХО дешевле, чем юнит — по крайней мере, исходя из моего опыта. Единственное — нужно не забывать их рефакторить и приводить постоянно в порядок, так же как и про-код. В этом смысле юнит-юнит чуть проще, т.к. обычно более изолированы в смысле реализации собственно тестового кода.

Плюс, эти блек-бокс тесты очень быстро начинают приносить отдачу, и команда начинает вовлекаться в процесс, видит что тесты могут помогать не только теоретически, но и практически.

В реальной жизни, конечно, редко начинаешь с вот такого полного «выкашивания» — а точнее рефакторинга тестов для всего и вся, скорее действуем ситуативно по мере поступления проблем и изменений в определенных участках кодобазы.

TDD на уже существующем коде невозможен по определению.

существующий код меняется. Перед изменением (функциональным) пишется тест, покрывающий изменение и остающийся красным пока желаемое изменение не выполнено. Это суть TDD — на новом, старом или любом коде.

Слегка сложнее с рефакторингом, где в идеале одни и те же тесты остаются зелеными до и после.

Если код не меняется, то естественно TDD тут нету по определению, так как нету и девелопмента.

не канон

канона тут вообще нет — каждый выдумывает сам себе по созвучности услышанных терминов.

Если прогер пишет и не понимает зачем, какую проблему он решает то это проблемы не юнит тестов, а его самого и/или проекта/начальства.

странно слышать от бота, который чуть выше в треде агитирует писать только юнит-тесты, потому что остальные слишком сложны — «нужно четко понимать требования».

Не надо лепить из юнит тестов святой грааль и сербрянную пулю

 — тут я запутался. Ты же вроде сам агитируешь за них всегда и только.

На существующем коде? Смешно.

смысл смеха от меня ускользает тут. Работаешь только с green-field?

Разницу между юнит, интегрейшен и е2е можешь в гугле поискать, все давно уже определено и не надо придумвыать новое.

 да, только не работает не фига как ты тут расписываешь. Сколько на митапах / конференциях / onboardings не спрашиваю кто следует TDD — 20 процентов максимум. Почему? Основой ответ «а я не знаю заранее куда, все поломается, а потом времени нет».

Открываешь унаследованный проект — 80% покрыто тестами тобой описанными, никому кроме писателя не нужными и не полезными. Начинаешь с выкашивания нах большинства тестов — особенно тех что на моках взращены, покрываешь нормальными блек-бокс тестами на нужных уровнях — и можно начинать делать TDD.

На, держи: . Аудио не очень, но в целом в тему.

В 60х были модны теории, о том что нужно разделять все на маленькие узко-специализированные задачи и строить типа производственный конвейер.

До 80х это как-то держалось, но начало схлопываться под нагрузкой быстро возрастающей сложности программных решений.

В 90х началась ажиль-революция, с тех пор эти теории в принципе не состоятельны, но умами Бота-Бота и пр. продолжают властвовать.

Найдешь что полезное — пиши тут.

Та зачем нам ТС, и так идет неплохо :)

Сказал — так отрезал. Ну пойди, погугли что такое настоящие юнит тесты как в оригинале было, и что такое настоящее TDD.

А вот от этого аж бомбануло, сам то хоть раз рефачил код без юнит тестов? Я — да. Это адъ и Израиль.
Какие проблемы, если это не js или другой язык без строгой типизации?

Это, кажется, к Bot Bot вопрос, но я попробую ответить.

Проблем никаких и без строгой типизации пока объем изменений невелик. С возрастанием же скоупа все быстро усложняется, и желательно опираться на «safety net» авто-тестов покрывающих всю область изменения. И целиком, а не маленькими кусочками, которые при сложении вдруг начинают работать немного не так, как из отдельных «юнит-юнит»-тестов казалось.

Юнит тесты не зависят от требований. Юнит тест тестирует, например, разворот массива или проход по дереву.

И много таких операций в среднестатистическом современном проекте? А «требования», читая тред выше, значит не тестируем и даже не понимаем — этим другие занимаются. Интересно. Что за индустрия, если можно поинтересоваться?

Чаще всего такой тест просто тестирует что один метод правильно вызывает 3 других метода.

Это типа по классике, такие методы моками обкладывать?

  fun aMethod(param:Int): Int { return if (param >= 0) { dependency1.callMethod1(param);          } else { dependency2.callMethod2(param);          } }

20% пользы от юнит-тестов потом в том, что они не позволяют другим девелоперам случайно или намеренно поменять (читай — поломать) работающий код (опять вспоминаем что он Закрыт для изменений!).

тут немного стало непонятно как и зачем ломать код «Закрытый для изменений». Наследованием, что-ли, злоупотребляете?

Функциональные тесты наоборот — почти всегда black-box и именно поэтому хорошо, когда проверочные тесты пишет другая команда или хотя бы другой разработчик. Потому что их делают на основании требований, не зная кода и не подгоняя тесты под него.

Цель автоматических тестов не нахождение багов (хотя это и может быть сайд-эффектом в процессе, так же как и любое копание в коде), а удостоверение что компонент или система функционируют как ожидалось. Во время написания и — в идеале — позже. White box or black box — не важно для результата.

Другой командой писать тесты противопоказано. Другим разработчиком из той же команды (или в паре) — всегда хорошо, как тесты так и любой код.

Привлекать людей со «свежей» головой к тестированию целесообразно для exploratory и compliancy тестирования. При этом ничего не мешает им (критически) использовать готовые авто-тесты, если упрощает работу.

Поэтому меня так напрягает когда пишут «юнит-тесты бесполезны, лучше используйте интеграционные». Это разные инструменты для разных целей! Это все равно что писать «маленький молоток бесполезный — он слабо бьет, хотите результата — всегда лупите кувалдой».

Ну пока от тебя я читаю «молоток, только молоток, про кувалды слышал, но они громоздкие и вообще чужие.»

Я вообще лично не против юнит-тестов на любых уровнях. Правильно примененные могут хорошо работать в TDD. Но если нужно выбирать или/или, то интеграционные (юнит — то есть в изоляции от других систем) всегда лучшее начало.

Сам писал и е2е и юнит тесты и интеграционные.

В моем опыте с точность до наоборот, интеграционные и особено гребыне селениум е2е тесты это всегда кошмар

Так, прежде чем спорить, еще раз: что мы называем юнит тестами, а что е2е и что интеграционные?

Для меня все три выполняются в изоляции, то есть внешние зависимости замоканны (WireMock etc.), а приватные зависомости (база, мессаджинг) запущены в изолированном докер-контейнере или замещенны in-memory implementation. Разница в фокусе теста.

Потому как селениум с токенами, адом и гоморой — это похоже про Integrated Environments — за них я вовсе не агитирую, а даже наоборот.

Очень странное мнение! Я всегда считал наоборот:

Очень хорошо, давай разбираться, говорим мы о разном, или контексты разные.

Юнит-тесты... После написания они не требуют поддержки, редко меняются, быстро выполняются и могут даже запускаться в фоне при написании кода (live unit tests in VS):

Не меняются? Код не рефакторится? Бизнес требования не меняются? В чем их польза тогда, кроме покрытия?

Функциональные тесты (интеграционные, E2E) — тестируют бизнес логику, требуют сложных тестовых данных и сложных проверок результата. В коде они проходят по всей иерархии обработчиков. Писать такие тесты непросто:
нужно четко понимать требования,

Ну да, в этом и суть. Какой смысл в девелоперах, не понимающих требования. Или у вас архитекторы переводят бизнес требования в целеуказания девелоперам?

нужно перед каждым прогоном готовить данные,

Да, в чем проблема? Ну приходится иногда несложные хелперы для создания тестовых данных делать, не космические технологии.

при проверке нужно учитывать «внешние» факторы (например текущее время или внешние зависимости).

Время — это 101 курса авто-тестирования.

Внешние зависимости фиксируются как есть для изолированного прогона. Дополнительно contract testing на интеграционных средах если меняются очень непредсказуемо и катастрофично. Хотя в 80 % случаев не окупается, как я пока наблюдаю.

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

обычно их не умеют писать. Если следить за производительностью, не перегружать все приложение и докерные имаджи на каждый чих — то вполне нормально и окупаемо. Случайным образом падают опять же если пишут неаккуратно, что впрочем легко в асинхронном случае.

При изменении в любых модулях интеграционные тесты обычно приходится менять — и не один а сразу много.

Добавление новой функциональности зачастую так же требует править старые тесты.

почему? IMHO, явный признак неправильного сетапа данных, и видимо большой повторяемости в тестах. Эти тесты у вас не тестеры или джуниоры случаем пишут?

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

Написание тестов после кода — это действительно боль. Если цель — просто наростить покрытие, то результат будет одинаково плох на любых уровнях.

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

Может у вас какая-то инженерная культура особая, но в моем опыте вниканий в кодобазы новых (для меня) проектов, даже кашистые и тормознутые высокоуровневые тесты приносили больше пользы чем 99% быстрых и безболезненных юнит тестов.

При этом автоматическое тестирование — это совсем другая история. Это black-box тесты должны писать и править совсем другие люди, а не девелоперы.

почему? Написание отдельно не-девелоперской сьюты тестов — сильный анти-паттерн. Может и оправдан в жестких монолитах, но не жизнеспособен.

Зависит от того, что ваша команда называет «Unit-тесты», и какие еще тесты пишутся.

Юнит-тестами разработчики нынче называют тесты минимальных блоков программ — классов или методов в изоляции. Такие тесты писать не стоит, по крайней мере в больших количествах, потому что они имеют тенденцию тестировать имплементацию, приносят мало пользы и наоборот вредят усложняя рефакторинг (изменение кода).

Что имеет смысл писать всегда (ну кроме разработки простого скрипта одним человеком), это более высокоуровневые функциональные тесты (интеграционные, E2E) — они менее ломкие, имеют лучший ROI, и в целом помогают разрабатывать быстрее даже на этапе PoC. Если сделаны умеючи.

Намного лучше и подробнее описано здесь: tyrrrz.me/...​unit-testing-is-overrated

При чем тут беженцы? Рулинг резали чтобы компенсировать потери от отмены налога на дивиденты — «беженцов» от брексита привлекать.

Походу дела выяснилось, что все еще хуже было когда вводили лимит на 120 км. от границы для рулинга — и тоже поотбирали у тех, кто успел из приграничных районов переехать до этого, так что с ретроспективностью тут действительно не очень.

Вроде 8-и летние уже выдавались с припиской что могут пересмотреть в любой момент, так что неприятно — но типа вот так. А вот то, что и десятилетние так же отменить хотели, и отменили бы — вот это уже не прикольно — там не было таких условий изначально.

Почитать интересно, конечно, но не совсем понятно в чем собственно профит. Ну попадаешь ты в автовыборку крупных (и не только компаний) чаще, и что? Это же не значит, что они даже твой профайл глазами посмотрели.

Как грубую аналогию можно привести: «я запостил свой имейл везде, теперь получаю намного больше писем».

Чому ж в ІТ досі немає свого «конвеєрного виробництва»?

Аналогии — территория опасная. Автомобильные могут быть более адекватны ІТ если скорректировать с наивного и, как показал развал RUP, вредного сравнения «разработка == конвейер» к более реалистичной «разработка ІТ == разработка конвейера».

Соответственно продукт этого конвейера — это автомобиль конкретной серии, а в IT — результат выполнения конкретного билда. (Ну или запуска, если так удобнее)

Разбработка может в свою очередь больше (массово-дешево, перекомбинирование известных зарекомендовавших себя компонентов) или меньше (специфическая ситуация, уникальный самопис) стандартизироваться, но все равно остается в принципе процессом немасштабированным, результатом которого является другой — уже масштабируемый процесс.

У софті немає ні своєї гайки, ні болта. За більш ніж 30 років існування індустрії програмного забезпечення ми перейшли від функційного до об’єктно орієнтованого (і назад), до методів машинного навчання та розподілених мікросервісів. Але нічого конкретного так і не вибрали.

Есть мнение, что не там ищете потому что. ФП против ОО, например — это вечный инь и янь, как функция против формы.

На самом деле болты вполне себе выписываются. Базы, git, веб сервера, процессы в цело по индустрии и т.п. Сравнивать скажем 20 лет назад и сейчас — совершенно разная материя. Просто материя намного более текучая, чем железные автомобили.