🗿Моменти, коли я зрозуміла, що ми робимо помилку у фреймворку

Колеги, привіт! Ніхто не застрахований від помилок, навіть коли маємо багато років досвіду - бо всі проєкти різні.
Сьогодні мені спало на думку поділитися моментами, у які я чітко відчула, що «фреймворк» з автотестами має проблеми.

⸻

🔹 1. Lazy imports у функціях
Коли проєкт великий і багато команд пишуть автотести, з часом з’являються “lazy imports” — імпорти всередині функцій.
Це дуже часто ознака циклічної залежності: коли два файли імпортують код один одного, і проєкт не запускається.
Щоб “обійти” помилку, імпорт ховають у функцію — але це лише тимчасова латка.
Таке свідчить, що архітектура helpers/libs побудована неправильно і потрібно розділити модулі чіткіше.

⸻

🔹 2. Падає все - замість конкретного тесту
На якісь зміни в коді повинен реагувати один конкретний тест або хоча б певний suite.
А коли падає все - це знак, що фреймворк не ізольований і тестова логіка переплетена.

⸻

🔹 3. Якісь тести навіть НЕ запускаються на CI, а ми цього і не помітили
Буває, що частина тестів просто НЕ раниться - і ми помічаємо це випадково.
Це трапляється, коли накручена складна логіка з тегами, test suites і фільтрами.
Тому правило просте: чим простіше CI-сети, тим краще.
Більше складності = більше шансів не помітити проблему.

⸻

🔹 4. Тест без assert — це не тест
Коли відкриваю тест і бачу лише кроки без жодної перевірки — це не тест.
assert — це серце тесту ❤️
Він має бути обов’язково й перевіряти саме те, на що фокусований тест.

⸻

🔹 5. Статус stage на CI ≠ статусу тестів
На етапі, де ми запускаємо тести:
▪️усі тести пройшли — stage зелений ✅
▪️упав хоча б один — stage червоний ❌

І здається, це очевидно… але як часто я бачила:

▪️у консолі, наприклад, 100 тестів, а в репорті — менше, бо під час генерації чи attach report логіка зламана;
▪️усі тести пройшли, а CI червоний
▪️найгірше - тести впали, а CI зелений. Це вже не просто помилка, а небезпека.

————-
Поділіться, якщо маєте, що додати 💬
Які ваші «червоні прапорці» у фреймворках?