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

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

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

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

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

Фаулер може писати що завгодно, але, наприклад, пітонівський unittest.mock універсально виконує і mock, і stub, і dummy, і фактично навіть ближче до stub (бо на невідомі виклики не дає винятків).

Ну як завжди, www.joelonsoftware.com/2002/05/06/five-worlds Ті хто сидить на «внутрішньому» софті — навіть якщо він в 2024 виглядає як перший бекенд веба, який далі є фронтендом для якогось мікросервіса — просто не думають, що є і інші світи.

Якщо по кожному пункту було б ще пару абзаців, що воно таке і чому, цю новину можна було б читати.

метод на 200-300 рядків — це дуже потужно, але майже ніколи — необхідно

Здорові думки у автора Від себе: якщо тести не тестять сценарії використання сервісу, тоді це просто для кавереджу 😊

я могу а я не могу.. бо щиток через одну кімнату і 2 стіни від місця де стаціонар не буде різати очі ...

тю... отепер все стало ясно ))) таке питання ...а з якого неба ви притягнули за вуха в тему яка почалася з мого «обурення» на пост в топіку про мобільні станції зе один костиль замість того щоб зібрати нормальну систему ) на гібриднику за 8 квт ) за...

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

99% тутешніх пише Круд сервіси. Ні бібліотеки, ні фреймворки, ні бази даних, а Круд сервіси. Навіть в цій статті всі приклади пов’язані з Users & Orders. В Круд сервісах юніт тести не потрібні в 99% випадків.

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

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