«діду, пий таблетки, а то отримаєш по жопі» — вибачте, не втримався 😀
Якщо люди менше будуть витрачати час на юніт тести
ви взагалі мій комент читали? Я пишу, що юніт тестів має бути більше. Я топлю за той підхід в тестуванні, коли код без юніт тестів не має взагалі прийматись тестерами. І прописую це в тест плані в якості Entry Criteria.
А тиж не хочеш бути без роботи, а хочеш писати статейки про яке лайно код девелоперів з юніт тестами.
Пхахахаха 😂
я ваш комент разів зо 5 прочитав, але цей потік свідомості не зрозумів. Спробуйте ще раз
зазвичай термінологія йде збоку клієнта
З боку клієнта іде бізнес (домен) термінологія. Коли ви намагаєтесь вирішити проблему, ви користуєтесь технічною термінологією.
щоб добре знати засоби вирішення проблеми нам треба знати предметну область
давайте одразу приклад — в вашому інтернет магазині замовник хоче мати чесний рейтинг товарів. Це такий, де рейтинг товару з одним відгуком на 5 зірочок не буле вважатись кращим за товар з 1000 відгуків на 4 зірочки. Знання в магазинній справі не допоможуть вам вирішити цю задачу. А математика, з термінами (середне, середне зважене, медіана та ін.) — допоможе
не про необхідність, а про кориснісь
true. Корисніше знати ніж не знати. Уявіть, в команді 2 програміста, один вчить математику, грає в го і катає на велосипеді, щоб тренувати тіло і розум, а інший... і так розумний.
Потім вони роблять естімейт одної і тої ж задачі, і один може її зробити за 4 години, а інший за 20, бо там ще розбиратись треба чи інші відмазки
Ні, ви не праві. Тестер має знати і вміти більше за юзера — теорію, тест дизайн, відповідні інструменти. Чим більше, тим краще.
В іншому випадку тестерів би не було, все б тестили юзери 😄
Мета юніт тестів, як і більшості тестів, не баги ловити, а перевіряти, що код працює так, як задумано. Саме тому юніт тести майже завжди проходять, бо код працює так, як ви задумали.
Всі тести важливі, але в правильній піраміді — юніт найбільше, потім менше інтеграційних, потім ще менше системних і зовсім трози приймальних
жодної негативної оцінки не вкладав. Сам же постійно пишу код і не розумію, як він працює. Але це нормально — оскільки я завжди сумніваюсь, то пишу юніт тести, запускаю свій код і постійно його тестую
екіпажу не було, наскільки я зрозумів, але ж не знімати через це САС з корабля
так є ж таке, TDD називається. Можна впроваджувати хоч в кожному першому проєкті
гг, це моя гуманітарна допомога тим розробникам, які, не зважаючи ні на що, продовжують писати херовий код ¯\_(ツ)_/¯
дякую, пофіксив одну кому. інші, наче, на своєму місці
я також був приємно здивований. насправді, там ціла лінійка стандартів якості 250хх, все відноситься до ПЗ
не згоден. От дивіться, ви почитали статтю, написану вище. Можливо дізнались щось нове, тобто навчились. Я ж не звинувачую вас, що ви вкрали інформацію зі статті. І навіть, якщо моя стаття надихнула вас написати власну статтю, все одно це буде вже ваша стаття, а не крадена моя ¯\_(ツ)_/¯
В перший місяц ми пишемо 100 тестів ( а це 1/3 від загального)
100 тестів — 20% від загальної кількості мануальних тестів, тобто економія у 8 годин у 1й місяць
+140 у другий — ще 16. Якщо маєте бажання, додайте в таблицю. На фінальний результат це радикально не вплине
Цитату бачу а от в розрахунках я цього не бачу.
🤦♂️то перечитайте статтю ще раз, що саме я рахую. там було щось про цілі автоматизації... я у вас вірю
мабуть у Вас мало знайомих
правда 🥲 зробив опитування у себе в ТГ, аж цікаво
автоматизаторів наймають для покриття усього (інколи навіть юніт тести та компонентні тести), брати найповільніші в розробці тести і на основі цього рахувати ROI якось не дуже
unit тести — це категорія must have, в той час як UI-автоматизація — додаткова плюшка. Саме тому і є запит на розрахунок ROI, щоб зрозуміти, чи є сенс робити, чи краще мануально ганяти
до кінці 1 місяця ми вже маємо ~ 100 тестів і це чомусь не враховується в ROI
можемо врахувати, але їх небагато і виграшем в часі можна знехтувати. Тому я почав рахувати прибуток з
Чому не враховуємо що тести можуть запускатися на кожен комміт, наприклад, разів 5 на день?( в моєму випадку це разів20-30 на день)
По-перше, враховуємо, ось пряма цитата
Ще кращим варіантом було б проганяти тести на кожен білд, але коли тестів багато, і час їх виконання сягає години — це може уповільнити процес розробки. Якщо є бажання і можливість, краще виділити невеликий окремий suite, що може виконатись швидко, після білда.
По-друге, я не чув success stories, коли всі регресійні UI-тести виконувались би на кожен коміт
Адже усі знають що чим раніше знайшли дефект тим він дешевше
а запобігти багам ще дешевше, го краще вимоги аналізувати
Чомусь не враховується що розробка тестів може йти паралельно з розробкою застосунку (наприклад АПІ тести)
бо для цього конкретного випадку ми рахуємо ROI саме UI автоматизації, про що я теж явно написав
Тут і надалі під автоматизацією тестування ми будемо мати на увазі саме UI-автоматизацію
Я так чекав цю статтю а вона не виправдала моїх очікувань
«Ну штош» ¯\_(ツ)_/¯
враховуючи, що в індустрії вцілому все ще є велика доля проєктів на PHP чи Cobol, все залежить від наполегливості клієнта
Згоден, розрахунок ROI не може бути універсальним, але я б його і в продукті рахував, просто щоб розуміти, яку користь ми можемо принести.
Саме тому я написав аж 3 потенційні цілі автоматизації, і окрім як зменшення часу на регресію, це регулярна тестова звітність, що, в теорії, має покращити ТТМ за рахунок раннього виявлення дефектів.
І чомусь всі коментатори, що пишуть про золоті хвилини простою проду нічого не кажуть про 3 мету — непропускання багів. Якщо у вас є постійний defect leackage, то чи є сенс від тої автоматизації. Сама по собі її наявніть якість не покращує
так, я люблю бурхливі дискусії! Взяли в останній DOU подкаст занадто лайтові теми і тепер там мало коментів і переглядів ¯\_(ツ)_/¯
hold my beer, як то кажуть, нам є що накинути 😂
Витратили час на ТДД, зекономили час на інтеграційному та системному тестуванні