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

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

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

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

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 і відео :)

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

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

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

exceptions

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

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

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

не підібрав іншого слова) ну тіпа загальні, common , general )) є варіант як краще написати? :)

з корисного для навчання може бути ще цей канал youtube.com/@from_a_to_qa :) там є декілька курсів невеличких :)

від авторів «пекельні борошна» :D

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

доречі а якщо хочете прочитати які питання задавати до самих інтервʼюерів то у мене теж тут статейка є dou.ua/forums/topic/41470

занадто товстий тролінг))) я такий не підійму )))

треба як іспанці — з 12 до 15 сієста))) і там спиш чи гуляєш)))