ви написали що

цей набір 25 патернів є, мʼяко кажучи, не ідеальним.

от мені цікаво які на вашу думку кращі за ці 25 якщо ви їх так не полюбляєте

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

90+% роботи в автотестуванні це вибір, що має бути в тесті, а що — не має

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

п.с. стосовно

Замість цього могло б бути написання на шаблонній мові з автогенерацією з неї

чи писали ви тести в форматі BDD? чи помітили ви використання патернів GoF в BDD? чи помітили ви НЕДОЛІКИ використання такого підходу? чи знаєте ви межі коли його можна використовувати а коли це зайвий прошарок абстракції? :) питання риторичне

а які на вашу думку патерни не є ідеальними? або які не можна використовувати у програмуванні?

цілі QA не мають проєцуватись напряму на конкретні рішення дизайну коду.

не зовсім зрозумів цей поінт — qa пише код, шоб код був розширяємим треба використовувати принципи ооп, солід, грасп, патерни програмування та автотестування. чи ви про щось інше кажете?

ну насправді так і є — принципи солід можуть конфліктувати з патернами гоф. той же патрен сінглтон -він є порушенням майже всіх принципів солід. але тим не менш інколи без нього ніяк :) в житті завжди треба шукати баланс :D

в принципі, в інтернеті є будь-що, якщо погуглити :D коли я шукав огляд книжки щоб вирішити чи читати її чи ні я не знайшов адекватного та повного огляду. тому вирішив його сам написати :) всі огляди були дуже поверхневі або присипані якоюсь агрегсією авторів.

доволі цікава думка — а можете більш детально розвивинути чому ви думаєте що патрени GoF — це інфоциганство?

п.с. відповім на питання

який звʼязок QA з темою

дуже жаль, що вам не пощастило працювати з автотестувальниками, QA та SDETами але тим не менш. робота QA/TAE/SDET це написання фреймворків для тестування та тестів на різних рівнях -юніт, інтеграційному та e2e, написання сервісів-заглушок, написання бібліотек для тестування, написання генераторів тестових даних, тощо. Без знання як це зробити достатньо масштабовано, гнучко, читабельно, розширяємо — рішення будуть виходити доволі осередкові.

так той, принципи GRASP в книгах Роберта Мартіна так само розглядаються і рекомендуються — навіть уц цьому огляді про них згадується -low coupling and hight cohesion, також використання поліморфізма :D ви точно читали ці книжки що критикуєте Роберта так яро? :D бо виглядає шо просто накидуєте на вентілятор :D

да, доречі у нього є на ютубчику ціла серія безкоштовних відосів можна знайти тут в секції Talks cleancoder.com/products

хм. цкава думка. Роберт Вважає їх саме підвидом ДТО(та і я теж в принципі) ось вставлю цитату з книжки сторінка 101:

thixalongmy.haugiang.gov.vn/...​media/1175/clean_code.pdf

Active Record
Active Records are special forms of DTOs. They are data structures with public (or beanaccessed) variables; but they typically have navigational methods like save and find. Typically these Active Records are direct translations from database tables, or other data
sources

код це є інтерпретація слів та ідей.
дивись, я пояснив тобі ідею яку Роберт Мартін хоче донести. ти продовжуєш писати токсичні коментарі з присмаком пасивної агресії.
якщо тобі не подобаються ідеї Роберта Мартіна — ти завжди можеш написати йому у лінкедин або його сайт cleancoders.com свої думки і попрохати його потестити, пописати код і тд.
на цьому слові, не маю інтересу продовжувати та спорити чи щось намагатись пояснювати далі, тому вибач, але бесіду завершено, на все добре :)

ну слово «запахи» по відношенню до коду використовується доволі часто на конфах та статтях різних. тому думаю саме слово «запахи» доречно вживати :) доречі, знайшов також в самій книзі в україньскому варіанті також вживається це слово — запахи :)

мені здається ти зараз вирішуєш не ту зовсім ту задачу і проблему про яку каже автор книги.

давай я поясню трішки моїх думок. як на мене поінт в тому що коли в тебе

...код.. код ... код... потім

if(time.expired() && !timer.recurrent()))

і після знову ...код ...код.... код.
— то ти тестуєш функцію вищого рівня. і тобі треба придумувати умови тестування самої функції ПЛЮС того шо в ній знаходиться(коду шо знаходиться в іф блоці — оця фігня з умовою коли таймер ексайпер і таймер не рекарент) .
яка може бути проблема тут? що методи таймера ексайред і рекарент працюють не так як ти очікуєш і агрегований результат виконання буде не тим шо ти очікуєш.
натомість автор пропонує винести умову в if в окрему функцію. що це тобі дасть?
по-перше — читабельність. коли ти читаєш складну умову в в if — подекуди с першого разу складно зрозуміти шо мав автор цього куска коду і набагато простіше якшо буде одразу пояснююча назва функції — не важливо це буде shouldBeDeleted(timer) чи timer.shoudBeDeleted() — з самої назви вже будуть очікування до того що відбуваєтсья в цьому куску кода і які очікування від його виконання.
по-друге, декомпозувавши таким чином — тестувати буде легше тому шо у тебе окремо вже будуть тести на перевірку самого кондішена if(твоєї нової функції коли вона вертає тру а коли фолс), і окремо перевірки на зовнішню функцію при цьому вже не думаючи про внутрішню реалізацію блоків іф.
ну а потім коли зʼвяляється більш легкий запис то уже може і прийти ідея як знизити цикломатичну складність фцункції зовнішньої шляхов введення або поліморфізму, або використовуючи патерн стратегію як приклад.

але я ще раз наголошу — ДУЖЕ ВСЕ ЗАЛЕЖИТЬ ВІД КОНТЕКСТУ ЗАДАЧІ.
чисто візуально — читати shouldBeDeleted(timer) чи timer.shoudBeDeleted() зручніше ніж
time.expired() && !timer.recurrent()

змінив на

розповсюджені

. вроде норм звучить. дякую за допомогу :)

прикольно! дякую за рекомендацію. додав у списочок собі після xUnit patterns читну

о!дуже класне питання як тестувати та навіщо саме так робити як радить автор.
відповім питанням яке допоможе у відповіді — а як вважаєш шо легче тестувати дві маленькі функції чи одну спагетті-функцію з іфами і вкладеностями? чи знайомий ти з поняттям цикломатична складність фуцнкції? і як її зменшувати? :)
відповіді на ці питання як раз і будуть служити рекомендаціями авторів(не тільки дядки Боба) до того чому саме так краще писати а не інакше :)
але знову ж таки, НЕ ЗАВЖДИ ))) бо є контекст проєкта, мови, задачі, тощо

ухти! дякую . ще не читав. оця я так розумію? www.amazon.com/...​onstruction/dp/0735619670

ось)) вже є — dou.ua/forums/topic/46119 і відео youtu.be/zwSH3VqEXwI :)

100% кожну рекомендацію слід розглядати враховуючи контекст мови, проєкту та задачі

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

а чого так категорично? :)

exceptions

вам цей комент теж ChatGPT допоміг написати? :D

прям в назві ж є ))) вона на ринку одна ))

абсолютно вірно дублювання та абстракції залежать від контексту і треба підходити завжди з розумом і враховувати контекст проєкта або задачі) я саме це і в кінці написав шо сліпо вірити всім рекомендаціям не треба :)
тести краще все ж коли є ніж нема :D
ну а приносити гроші — це основне заради чого ми пишемо код) інакше це просто хоббі або олімпіадне програмування(хоча й там гроші він приносе) :D