
Привіт друзі! Сьогодні хочу поділитись з вами цікавим багом, що аналізував нещодавно.
Кілька років тому писали ми для нашого замовника одну досить складну фічу – багато математики, кілька десятків вхідних параметрів, що збираються як з веб сервісів, так і з бази даних та вводу користувача. З десяток вихідних параметрів з результатами. Для тестування фічі я розписував великі Excel таблиці з дизайном та тестами на всі можливі комбінації. Тестував то все нещатся вручну, бо розробники казали, що нереально написати unit тести на таку складну та розгалуджену фічу. А автотести написати теж не варіант, оскільки багато параметрів я просто не контролюю 🤷♂️
Нещодавно замовники попросили оновити фічу, додати ще більше вхідних параметрів, що впливали б на обчислення. І наш архітектор зробив вольове рішення зарефакторити все, але зробити нарешті нормальні unit тести та припинити мануальне страждання 😜 (не всі супергерої носять плащі)
Я підготував йому сети даних, він написав тести і сталось чудо – фіча готова! Тести “зелені” ✅. Зробив смоук руками – жодних проблем. Видали в UAT і майже одразу отримали баг від користувачів – фіча працює не правильно 🤯. Але ж як так може бути?
Лише після аналізу я зрозумів, що велика гнучкість системи (поведінку якої можна буквально змінити за допомогою конфігів, не змінюючи код) стала для нас причиною помилки, яку навіть unit тести пропустили.
Коротше: Для тестів я прописав всі вхідні дані явно. І не врахував (так, мій косяк), що система, в разі відсутності деяких даних (прийшов null, наприклад), бере аналогічні значення з сусідніх об’єктів (типу default, але не зовсім. Складна конфігурація). Чим і скористався користувач, законфігурувавши мінімально можливий датасет. А помилка як раз була в тому, що дані брались не з того об’єкту, що і вплинуло на подальші обчислення.
Мораль: якби я проганяв, як раніше, тести руками – знайшов би той баг самотужки (бо в міру лінивий і не конфігурував би всі повні набори даних), але я повірив, що unit тести покривають всю логіку (сам же допомагав їх писати) і smoke’у буде достатньо.
А чи були у вас подібні випадки, коли ви довіряли автотестам більше, ніж потрібно?
Наявність юніт-тестів не нівелює необхідність проганяти щось більше, ніж просто смоук. Особливо коли складна логіка роботи системи
Тому твердження з заголовку – хибне, зрештую, субєктивне.