Англійська для dbt Unit Tests і типових контрактів

dbt став стандартним шаром трансформації в сучасних стеках даних, і його екосистема тестування значно зріла з введенням тестів одиниць і моделей контрактів. Інженерам даних, які працюють у крос-функціональних командах, потрібна точна англійська лексика для цих функцій, щоб писати ефективну документацію, проводити ретельні перегляди коду і повідомляти стандарти якості даних аналітикам і зацікавленим сторонам продукту.

Ключовий словник

** Модельний контракт ** — налаштування dbt, яке накладає схему виводу моделі, гарантуючи, що вказані стовпчики існують з визначеними типами даних і обмеженнями, незалежно від змін, які відбулися у попередніх версіях.

• “Додати модель контракту до моделі замовлень, щоб будь- які зміни, які відбуваються на початковому етапі, що вилучають стовпчик customer_ id, негайно призводили до невдачі збирання, а не до тихого створення нульових значень на кінцевому етапі.” *

** Обмеження на рівні стовпчика ** — правило, яке застосовується до певного стовпчика у моделі контракту, наприклад, not_ null, unique, primary_ key або нетиповий вираз перевірки. “Встановити обмеження not_null на order_total у контракті — якщо будь- яке перетворення вгорі вводить нулі, матеріалізація зазнає невдачі з явною помилкою.”

** Unit test ** — dbt- тест, який перевіряє логіку SQL моделі за допомогою надання імітації вхідних даних (фіксацій) і стверджує, що модель створює очікуваний вивід, не торкаючись фактичних даних складу.

• “Написати тест- одиницю для моделі атрибуції доходів, використовуючи дані про пристрої, що охоплюють крайні випадки, такі як розділені замовлення і повернення коштів — це неможливо гарантувати у сирих даних про виробництво.” *

** Визначення тесту YAML ** — декларативний блок YAML у тестовому файлі проекту dbt, який вказує модель, що тестується, імітовані вхідні дані і очікувані рядки виводу.

• “Додати визначення тесту YAML до каталогу tests/ unit/ поряд з файлом схеми моделі, щоб переглядачі могли бачити тести без переходу до сховища.” *

** Заданий/ очікуваний шаблон ** — структура тестування одиниці dbt, де задані блоки визначають імітовані вхідні дані для моделей або джерел, а блок очікувань визначає рядки, які має створити перевірена модель. “Структурувати кожен тест модулів з вказаним блоком для кожного джерела посилання і блоком очікування для виводу — це віддзеркалює шаблон « організувати- діяти- стверджувати » з тестування програмного забезпечення.”

** Дані про фіксуванні ** — невеликі, створені вручну набори рядків, визначені у блоках даних і очікувань тесту одиниці dbt, призначені для ізоляції певної логіки перетворення.

• “Зберігайте дані про пристрої мінімальними — від трьох до п’ яти рядків на блок зазвичай достатньо, щоб охопити щасливий шлях і найважливіші випадки країв.” *

** Матеріалізація ** — стратегія, яку dbt використовує для збереження виводу моделі у сховищі, наприклад, таблиці, перегляду, інкрементального або ефемерного.

• “Використовувати інкрементну матеріалізацію для моделі подій, щоб кожен запуск додавав нові записи, а не перебудовував всю таблицю.” *

** Перевірка схеми ** — старіша термінологія dbt (тепер називається перевіркою даних у dbt Core 1. 1+) для тверджень, які виконуються за фактичними даними сховищ, такими як перевірка унікальності або посилання на цілісність.

• “Крім тестів модулів, які перевіряють логіку з інструментами, додайте тести схем до таблиці виробництва, щоб виявити проблеми з якістю даних, які з’ являються лише у реальних розподілах даних.” *

Звичайні фрази

• «Модельний контракт буде ловити зміни в схемі, перш ніж вони досягнуть рівня BI.»
• «Вибачте за моделі в даному блоку — ми хочемо перевірити нашу логіку в ізоляції, а не джерело даних.»
• «Блок очікувань повинен відображати саме те, що модель виробляє для даних вхідних даних»
• «Матеріалізуйте цю модель як таблицю, якщо нижні запити повільні; використовуйте перегляд, якщо вартість зберігання є проблемою.»
• Запустити dbt build для виконання як перетворень, так і всіх пов’язаних з ними тестів в порядку залежності

Приклади речення

При поясненні тестів модулів аналітику даних, який не знайомий з тестуванням програмного забезпечення:

• “Тест дбт надає нам змогу перевірити правильність нашої логіки SQL за допомогою подачі невеликих, ретельно обраних рядків і перевірки того, чи відповідає вивід нашому очікуванню. Це як тестування функції калькулятора: ви даєте йому певні вхідні дані і підтверджуєте, що вивід правильний, без необхідності заповнення реальної бази даних.”*

Під час написання опису запиту на звантаження для нового контракту моделі: “Ця PR додає модельний контракт до моделі customer_lifetime_value, застосовуючи обмеження not_null і primary_key для customer_id і обмеження not_null для ltv_90d. Будь-яка зміна вгору, яка порушує ці обмеження, тепер не вдасться CI-збірці, а не безшумно пошкоджувати панель BI. ”

Під час перегляду коду:

• “Вказаний блок використовує назви таблиць виробництва замість значень інструментів. Тести на одиниці повинні посилатися на імітовані вхідні дані, тому результат тесту є детермінованим незалежно від того, що знаходиться на складі в момент запуску тесту. “*

Професійні поради

• Розрізняти ** тести одиниць ** (логічне перевірка з пристроями) від ** тестів даних ** (твердження якості проти реальних даних складу) — об’ єднання їх спричиняє плутанину щодо того, що означає невдача тесту.
• Використовуйте фразу “контрактно-ориентированная разработка” при розробці моделей контрактів для інженерного керівництва - це сигналізує про вирівнювання з найкращими практиками інженерії програмного забезпечення і робить концепцію миттєво впізнаною.
• Під час запису даних інструменту включайте принаймні один рядок ** з крапкою ** поруч з гладким шляхом — нульові значення, нульові кількості і межі дат є поширеними джерелами помилок перетворення.
• Описувати моделі контрактів як **“захисні огорожі схеми на шарі матеріалізації” **, коли пояснювати їх користувачам даних, які турбуються про надійність панелі приладів.

Практичні вправи

1. Молодший аналітик запитує, чому потрібні тести модулів, якщо ви вже маєте тести схем. Напишіть два речення, у яких поясніть різницю між ними і чому обидва цінні.
2. Ви пишете тест- одиницю для моделі, яка обчислює 7- дневe середнє зсувне. Які рядки інструментів ви б включили до вказаного блоку, щоб перевірити крапковий випадок на початку історії користувача?
3. Написати опис у одному реченні типового договору, який підійде для коментаря запитів на звантаження, адресованого особі, яка не є інженером.

Навигація Nuance: спільні фрази в dbt тестування дискусії

Будьмо чесними — технічний жаргон може бути особливо складним, коли ви будуєте свій професійний англійський словник. dbt тестування, з його акцентом на точність і ясність, не є винятком. Крім простого знання таких термінів, як «тестування пристроїв» або «модельний контракт», розуміння того, як ці концепції обговорюються в команді, є ключовим для ефективної співпраці. Часто, це не просто про те, щоб вказати проблему; це про те, щоб оформити її таким чином, що запрошує конструктивний зворотній зв’язок і забезпечує, що кожен розуміє бажаний результат.

Однією з поширених перешкод для не-рідних мовців є непряме використання, яке іноді зустрічається в коментарях до перегляду коду. Замість прямого повідомлення « Цей стовпчик має бути унікальним », ви можете побачити таке повідомлення: « Чи можемо ми розглянути параметри, щоб забезпечити різні значення у цьому стовпчику? » Ця фраза, хоча і ввічлива, може здатися вам нечіткою, якщо ви звикли до більш чітких інструкцій. Аналогічно, повідомлення Slack, що обговорює невдалий тест, може читатися так: «given/expect не зовсім захоплює очікувану поведінку - можливо, нам потрібно вдосконалити твердження?» Ключовим тут є визнання того, що технічні обговорення часто включають тонкі пропозиції і прохання про пояснення, а не тупу критику. Навчання розпакувати ці нюанси — ставити наступні питання, такі як: «Чи можете ви розібратися, що означає «вдосконалити» в цьому контексті?» — це життєво важлива навичка. Не вагайтеся запитати про приклади бажаного результату; набагато краще шукати пояснення заздалегідь, ніж неправильно трактувати намір і витрачати час на роботу над чимось, що спочатку не передбачалося. Крім того, розуміння різниці між заявою про технічне обмеження («Стовпець повинен бути не нульовим») проти запитом на зміну в дизайні («Ми повинні розглянути додавання типового значення») важливо для ефективного спілкування.

Іншою областю, де словник може викликати плутанину, є навколо формулювання очікувань в описах PR. Замість того, щоб просто сказати «Додано тести одиниць», хороший опис PR може сформулювати * чому * тести були додані: «Вреалізовано тести одиниць для перевірки нової логіки обчислень в моделі customer_lifetime_value, забезпечуючи точне повідомлення і запобігаючи потенційним розбіжностям даних». Це надає контекст і демонструє розуміння ширших наслідків. Нарешті, пам’ ятайте, що документація — як у dbt, так і поза ним — часто написана з певною мірою формальності; адаптація вашого власного написання до цього стилю може полегшити розуміння.

dbt test --vars={"my_test_variable": "some_value"}

За допомогою цієї команди можна продемонструвати використання змінних у тестах dbt, що є поширеною практикою налаштування тестів на основі динамічних значень. Зрозуміти, як ці змінні використовуються і посилаються в рамках визначення тестів, є ключем до ефективного управління і інтерпретації результатів тестів.