Технічні статті й дайджести

Ну як завжди, www.joelonsoftware.com/2002/05/06/five-worlds Дякую. Я вже почав відчувати себе занадто старим, бо знаю про Фаулера, а виявляється, що є ще навіть ті хто пам’ятають Джоела :)

Фаулер може писати що завгодно, але, наприклад, пітонівський unittest.mock Фаулер (а можливо навіть не він) спробував впорядкувати і класифікувати підходи. Те що є купа людей, які іпали в них розбиратись у відносно базових підходах — це їх проблема.

так а хіба не свідки інтверторів прийшли сюди випендрюватися? буквально третій root комент — випєндрьож. швидше, мабуть, чим лінунксятніки в теми про вінду чи макосятніки в будь яку тему про комплюхтори.

Так, але, на жаль, часто моки використовують там, де їх використовувати не треба Що значить «не треба»? Ви можете чітко показати, що є сценарій де це «не доцільно», тобто заважає (саме це зазвичай мають на увазі коли говорять «не треба»).

Понятно, вам нужно не решение, а поговорить и повыпендриваться.

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

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

Дякую за статтю

як тіко тре шось мокати — то є явний маркер порушення SOLID

як правило, поєдную Advent of Code з вивченням нової мови. цього року вирішив робити таски на Elixir (до цього не мав досвіду з Elixir та Erlang). давно не мав такого фану при вирішенні завдань.

просто не думають, що є і інші світи. Тут трохи не згодний. Книжки про тестування описують універсальні рішення без привʼязки до якихось деталей проекту. Я не бачив книжок на кшталт «Автоматизація тестування CRUD» чи «Unit-тестування вбудованих рішень».

Якщо контролери-сервіси-даошки мають однорядочкові методи, котрі просто викликають одне одного і перетягують дані з бази на UI — тоді так, змісту з юніт-тестів небагато.

Якщо в мене всередині сервісу є ще чотири сервіси, я замокав усі чотири, а в самому тесті перевіряю, що метод вертає те, що вертає четвертий мок в порядку — то я успішно перевірив моє знання Mockito, але аж ніяк не бізнес-логіку.

Ключова фіча моків — це можливість перевірки взаємодії/інтеракції з об’єктом. Так, але, на жаль, часто моки використовують там, де їх використовувати не треба. Цитуючи вас же ж: Просте правило: ми мокаємо залежності юніта, який ми тестуємо.

У порядку дискусії скажу, що цикломатична складність більш важлива, ніж проста кількість рядків. Про «майже ніколи» — да, але це не має перетворитись в «ніколи», і не має бути самодостатнім принципом.