Привіт друзі! Вибачте, трохи випали з інфо поля, бо погода аж шепче “не снікерсуй – прокрастинуй”. Зібрались з силами, напридумували купу ідей, продовжуємо писати!
За останній місяць вже декілька разів в різних активностях в мене постає питання – як же зробити автоматизацію тестування правильно в сучасному світі мікросервісів? Точніше, як налаштувати, інтегрувати в CI/CD процес і зробити їх більш-менш автономними, що не потребують щоденних переконфігурацій? Я не знайшов якихось універсальних інструкцій, тому почну просто перелічувати ті проблеми, з якими зустрівся особисто чи зміг передбачити, а потім ті рішення, які допомогли мені їх вирішити. Якщо вам сподобається, продовжу перелік пізніше. Поїхали!
❌ Коли наші автотести запускаються, вони очікують, що в системі, що тестується, будуть певні дані та об’єкти, з якими можна працювати. Наприклад користувач, щоб їм залогінитись, об’єкт, який можна модифікувати (товар в інтернет магазині можна купити). Проблема з даними: в різних енвах вони можуть бути різні чи їх не бути взагалі. Дані можуть приходити з 3rd-party, яку ви не контролюєте, дані в момент виконання тесту може дуже невчасно заблокувати мануальний тестер, що як раз ретестить баг…
❌ Якщо програма, що тестується, має мікросервісну архітектуру, як варто запускати автотести? Після деплою кожного окремого сервісу? А що буде, якщо під час тесту станеться новий деплой? А якщо вночі – а може це не достатньо часто?
✅ Якщо це можливо, автотести перед виконанням мають встановити default конфігурацю та набори даних. Кращий варіант – з бекапа, гірший – додатковими кроками тих ще тестів
✅ Окрім DEV, TEST, UAT я б завжди хотів бачити окреме середовище виключно для автотестів. Це має вберегти від ручного втручання в дані і полегшити їх збереження в default стані (чи спростить відновлення даних з бекапу)
✅ Часто буває, що окреме середовище не виділяють, і все тестування проводиться в TEST (чи навіть в DEV, а TEST просто немає) – в такихи випадках можно домовитись з командою про унікальні сети даних, з якими ніхто, крім автотестів не має взаємодіяти
✅ Якщо ваші тести залежать від мінливих 3rd-party, можна спробувати використати mock сервіс (тобто знов все іде до окремого середовища) чи переглянути кількість таких тестів – якщо вони вкрай нестабільні, можливо швидше виконати їх руками, ніж костилити рішення?
✅ Якщо ваші автотести мають виконуватись після кожного білда, можна спробувати заблокувати (створити чергу) подальші білди, поки тест не завершиться – але цей варіант може сильно затягнути процес розробки і тестування. Знову ж таки, тут краще мати окремий енв для таких черг чи жорстко лімітувати час на прогон автотестів – наприклад смоук не більше ніж 5 хвилин
✅ Для мене вийшло оптимальним планувати запуск автотестів щоночі, а ще розбити великий regression suite на кілька менших, що запускаються в різний час, деякі навіть не щодня
Фух 😩 Такі думки. А з якими проблемами зустрічались ви та як їх вирішували? Пишіть в коментарях! А я вже думаю над другою частиною 🤓