22 правила тестування, які ми додали в AGENTS(.md)
Більшість dbt-проєктів провалюються з дуже простої причини — ніхто не визначив чіткі правила тестування.
Якщо у вашому проєкті немає задокументованих стандартів тестування, у вас немає надійності даних.
Ми зафіксували такі правила в AGENTS(.md), щоб і люди, і AI-агенти працювали за однаковими стандартами.
👇
1. Усі моделі повинні мати тест первинного ключа (not_null + unique).
2. Якщо у моделі немає природного первинного ключа — створюємо surrogate key через dbt_utils.generate_surrogate_key і тестуємо його.
3. Staging-моделі тестуємо максимально ретельно, бо вони є фундаментом для всього проєкту.
4. Якщо колонка не змінює значення між шарами (staging → intermediate → mart), тестуємо її в staging і не дублюємо тести далі.
5. Mart-моделі завжди повинні мати тест первинного ключа. Якщо його немає — модель не готова до продакшну.
6. У marts можна повторно тестувати критичні бізнес-поля. Краще перестрахуватися.
7. Колонки, які ніколи не повинні бути NULL, повинні мати тест not_null. Upstream-джерела можуть змінити свої обмеження будь-якої миті.
8. Колонки, які повинні бути унікальними, мають мати тест unique.
9. Для boolean колонок додаємо accepted_values з TRUE і FALSE, щоб уникнути значень 0/1 або "TRUE"/"FALSE".
10. Якщо boolean ніколи не може бути NULL, додаємо також not_null.
11. Для категоріальних значень (status, state, category) завжди додаємо accepted_values.
12. Якщо категорія створена через CASE WHEN, також додаємо accepted_values, щоб уникнути неочікуваних змін у логіці.
13. Колонки з CASE WHEN зазвичай повинні мати not_null (якщо тільки NULL не очікується).
14. Для складних CASE-виразів варто писати unit-тести, щоб зміни не ламали логіку.
15. Relationship-тести можуть бути дорогими (часто роблять full scan). Використовуйте їх обережно, бажано на staging.
16. Для великих таблиць використовуйте WHERE-обмеження, щоб зменшити час виконання тестів.
17. Custom (singular) тести — для специфічної бізнес-логіки. Але спочатку перевірnt готові dbt пакети, там є багато корисного.
18. dbt_utils.expression_is_true — для перевірки SQL-виразів, наприклад: net_amount + tax_amount = gross_amount.
19. dbt_utils.not_empty_string — для перевірки, що рядок не порожній.
20. dbt_utils.accepted_range — для перевірки числового діапазону.
21. dbt_utils.recency — для перевірки актуальності даних.
22. dbt_utils.not_null_proportion — якщо допускається невеликий відсоток NULL.
