После исправления
Не ограничивайтесь зелёной отметкой теста. Проверьте несколько файлов, которые уже загружались в систему раньше, и убедитесь, что новая версия не изменила их смысл. Сохраните исходные данные и контрольные результаты отдельно от кода. Если ошибки зависят от формата выгрузки, сопоставьте этот процесс с проверкой CSV-отчёта: та же привычка отслеживать происхождение каждой колонки помогает и при импорте.
Почему «обычный» файл обманывает
CSV кажется простым: строки, запятые, заголовок. В реальной выгрузке встречаются точка с запятой, кавычки внутри поля, перевод строки в описании товара, пустая цена и разная кодировка. Нейросеть может быстро написать функцию импорта по одному красивому образцу и столь же быстро создать тесты, которые подтверждают только этот образец. Начните не с кода, а с контракта: какие колонки обязательны, какие разделители допустимы, что делать с дубликатом и какую ошибку показать пользователю. Если правило не записано, модель будет его придумывать. Придуманное правило может выглядеть логичным и всё же повредить данные.
Разделите синтаксис и смысл
Синтаксическая ошибка — не закрыта кавычка, строка содержит лишний разделитель, заголовок не совпадает с ожидаемым. Смысловая — отрицательная цена там, где она невозможна, повторный артикул или дата вне допустимого диапазона. Эти классы требуют разных сообщений и разных действий. Парсер может правильно прочитать значение «-10», а бизнес-правило должно его отклонить. Попросите ИИ сначала предложить матрицу случаев, а не писать реализацию. В матрице укажите вход, ожидаемое число записей, ожидаемые ошибки и политику частичного импорта. Сверьте каждую строку матрицы с реальным требованием проекта.
Фикстуры, которые стоит хранить
Сделайте отдельные маленькие файлы: корректный минимальный; поле с запятой в кавычках; перенос строки внутри описания; пустое необязательное поле; отсутствующий обязательный столбец; лишний столбец; дубль артикула; кириллица в UTF-8; файл с BOM; слишком длинное значение. Один гигантский «плохой CSV» трудно диагностировать: тест упал, но непонятно, какое правило сломано. Модель поможет сгенерировать примеры, однако разработчик обязан открыть их обычным текстовым редактором и убедиться, что байты действительно отражают задуманный случай. Особенно часто незаметно исправляются кавычки и переводы строк.
Проверьте сохранность данных
После импорта сравните количество входных и созданных записей с учётом отклонённых. Если файл содержит сто строк данных, а приложение создало девяносто девять карточек и не сообщило об ошибке, зелёный статус бесполезен. Сохраняйте идентификатор входной строки в отчёте импорта. Для числовых полей проверьте десятичный разделитель и валюту; для даты — формат и часовой пояс. Не переводите пустое значение в ноль автоматически, если ноль имеет деловой смысл. Пропущенную цену лучше пометить как требующую проверки. В разборе проверки таблицы перед отчётом рассмотрена близкая задача: происхождение числа должно быть прослеживаемым.
Не давайте модели писать ожидание из кода
Распространённая ошибка автоматической генерации тестов — сначала прочитать реализацию, а затем объявить её поведение правильным. Например, функция молча пропускает ошибочную строку, и тест ожидает именно пропуска, хотя требование просит остановить импорт и показать отчёт. Записывайте ожидаемый результат из документации до того, как просить ИИ создать тест. Затем сравнивайте реализацию с ожиданием. Если документация отсутствует, обсудите спорные случаи с владельцем продукта. Условие «как получится» не является контрактом. Для критичных данных полезен режим предварительного просмотра без записи в основную базу.
Что делать с частично корректным файлом
Есть два разумных подхода: отклонить весь файл или импортировать верные строки и выдать список ошибок. Выбор зависит от бизнеса. Для учётных операций частичный импорт может оставить систему в противоречивом состоянии; для большой библиотеки изображений он может быть приемлем. ИИ не должен принимать это решение по своему вкусу. После выбора пропишите транзакционность, формат отчёта и возможность повторной загрузки без дублей. Проверьте сценарий, где пользователь исправил одну строку и отправил файл снова. Если приложение удвоило остальные записи, первая проверка была недостаточной.
Тест в интерфейсе не менее важен
Даже правильный парсер можно испортить интерфейсом. Пользователь должен видеть, какой файл выбран, сколько записей распознано, какие строки отклонены и что будет записано после подтверждения. Проверьте, можно ли скачать отчёт об ошибках без раскрытия чужих данных. Если загрузка длится долго, повторное нажатие кнопки не должно создать второй импорт. На мобильном устройстве сообщение «ошибка 12» без номера строки и объяснения почти бесполезно. Попросите ИИ предложить ясные формулировки ошибок, но проверяйте их с человеком, который будет исправлять файл, а не только с разработчиком.
Регрессия и FAQ
Храните проверенные фикстуры в репозитории, не включая реальные личные данные клиентов. После обновления библиотеки парсинга прогоняйте весь набор. FAQ: можно ли заменить CSV на Excel и забыть о проблемах? Нет, часть вопросов с типами данных и пустыми значениями останется. Нужен ли огромный тестовый файл? Сначала нужны маленькие случаи на каждое правило; нагрузочный тест добавляется отдельно. Может ли ИИ сам сказать, что покрытие полное? Нет, полнота определяется вашим контрактом и инцидентами реальных пользователей. Хороший импорт не просто принимает файл — он объясняет, что именно произошло с каждой записью.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.