# Написала тести для самих перевірок, з'ясувавши, що перевірка, яка отримує лише чисті вхідні дані, одного дня звітуватиме про чистоту, бо нічого не прочитала: підклала помилку правопису, щоб підтвердити, що перевірка орфографії її знаходить, і взяла діапазон ідентифікаторів із бази даних, а не з числа в тесті. серпень 2026 **Ситуація.** Проєкт запускає для власного вмісту набір власних скриптів перевірки — перевірку орфографії, перевірку діапазону ідентифікаторів, перевірку стилю викладу, перевірку узгодженості чисел. Кожен із них місяцями давав зелений результат. Скрипт перевірки, який бачив лише бездоганні вхідні дані й завжди повідомляв, що все гаразд, неможливо відрізнити від скрипту, який узагалі нічого не читає, і в наборі не було тесту, здатного їх розрізнити. **Завдання.** Скрипти перевірки треба було змусити довести, що вони взагалі здатні завершитися з помилкою, а фікстури, з якими вони звіряють дані, мали перестати бути копіями описуваного, які доводиться оновлювати вручну. **Дія.** Скрізь застосовано той самий підхід: підкласти саме той дефект, який скрипт перевірки має знаходити, і вимагати, щоб він його знайшов. Перевірці орфографії подають навмисно неправильно написане слово, і тест не проходить, якщо прогін завершується без зауважень. Перевірці стилю викладу подають текст від першої особи, і вона мусить його відхилити. Перевірці на модні слівця подають заборонене слово. Кожен такий тест невеликий, і кожен закрив реальну сліпу зону, бо, як з'ясувалося, два скрипти перевірки читали вужчий набір файлів, ніж зазначено в їхній документації, і непомітно пропускали частину вмісту. Друга зміна стосується того, звідки тест бере очікувані значення: перевірка діапазону ідентифікаторів раніше порівнювала дані з числом, записаним у файлі тесту, тож кожне додавання вмісту вимагало редагувати тест, а той, хто оновлював число, не перевіривши, фактично вимикав перевірку. Тепер вона обчислює діапазон на основі бази даних, тож перевірка описує дані, а не застарілий спогад про них. **Результат.** Тепер для кожного скрипту перевірки в проєкті є тест, який доводить, що на хибних вхідних даних той завершується з помилкою, а перевірки діапазону беруть дані з джерела істини. Незручно те, що це виявило: щонайменше у двох місцях зелена перевірка невідомо скільки часу нічого не означала, і заднім числом неможливо з'ясувати, що крізь неї пройшло. --- - Роль: Інженер з тестування та якості - Категорії: [Бази даних](https://data.engineer.company/uk/categories/databases/), [Управління даними](https://data.engineer.company/uk/categories/data-governance/), [Автоматизація та CI/CD](https://data.engineer.company/uk/categories/automation/), [Тестування та QA](https://data.engineer.company/uk/categories/testing/), [Python](https://data.engineer.company/uk/categories/python/) - Послуги: [Data Governance та якість даних](https://data.engineer.company/uk/services/data-governance/), [DevOps та автоматизація CI/CD](https://data.engineer.company/uk/services/devops-cicd/), [Технічне лідерство та консалтинг](https://data.engineer.company/uk/services/technical-leadership/)