22 правила тестування, які ми додали в AGENTS(.md) Більшість… — Data Їнженер

Data Їнженер@data_engineer_ua · 615 subscribers Open in TelegramOpen

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.