У меня есть несколько файлов с кодом тестирования кода (который использует класс «unittest»).
Позже я обнаружил, что было бы неплохо также проверить целостность базы данных. Я поместил это в отдельное дерево каталогов. (Такие вещи, как ключи имеют правильный формат, родительские и дочерние узлы указывают правильно и тому подобное. Редактировать: это проект nosql, где я не могу полагаться на проверки на уровне базы данных, ссылочную ссылочную целостность и тому подобное.)
Я использую тот же класс unittest для тестов целостности.
Теперь мне интересно, имеет ли смысл держать это отдельно? Чтобы проверить целостность данных, я часто дублирую части кода, которые я использую для проверки кода, который обрабатывает данные.
Но это не то же самое. В тестах кода используются тестовые базы данных (которые удаляются после каждого теста), и тесты целостности подключаются к оперативным данным и анализируют их. Тесты целостности, которые я хочу вызвать из cron и отправить сигнал тревоги, если что-то случится в действующей базе данных.
Как бы вы справились с этим? Существуют ли стандарты для такой настройки? Каков ваш опыт?
Моя тенденция - помещать все в один файл, что приведет к тому, что cron также выполнит тесты кода в производственной среде.
Редактировать: Меня также вдохновляет стремление сделать проект простым и не допускать слишком большого количества файлов, затрагиваемых одной задачей или рабочим процессом. Без всего тестирования у меня уже есть файл класса, подкласс, связанный класс, некоторые библиотечные (вспомогательные) файлы и основной код. Тестирование добавляет один файл. Это помогает мне сосредоточить внимание во время кодирования, это меньше стресса, и я считаю, что я делаю меньше ошибок, и я могу быстрее запомнить и найти определенную часть кода с меньшим количеством затронутых файлов. Здесь может помочь только один файл тестирования на рабочий процесс. Если я держу его отдельно, есть 2 файла (тестирование целостности данных и тестирование кода) и, возможно, 3 (общая библиотека для обоих). Абстракция добавит сложности.
Edit2: Сейчас я немного реорганизую рефакторинг и перемещаю только файлы тестирования данных в то же дерево каталогов, где и тестирование кода, но сохраняя разные файлы с именем, указывающим «целостность» или « тестирование». Я не буду (пока) объединять файлы, потому что против этого рекомендуют 2 человека, и я верю в их опыт и советы на данный момент. Я буду жить с дублированием кода на данный момент.
Edit3: Я забыл упомянуть, что выбор тестов за цикл не определяется древовидной структурой в этом случае. Тесты перечислены в мастер-файле, поэтому у меня есть 2 мастер-файла: «целостность» и «тестирование кода» в настоящее время, и тест может жить в одной структуре управления.
Может быть, больше людей ответят. Спасибо вам за ценный вклад, который уже помогает мне разработать окончательную структуру!
Edit4: Я сделал больше рефакторинга сейчас. Кажется, я должен сохранить 2 файла, но с немного измененным назначением. Один предназначен для планового мониторинга на рабочем сервере. И еще один для развития. Но в обоих файлах могут быть тесты целостности или тесты кода. И в обоих файлах операции могут выполняться над тестовыми базами данных (которые стираются после теста) и над постоянной базой данных (каждая имеет постоянную базу данных, рабочий сервер и сервер разработки). И одна важная вещь: я перемещаю много общего кода из тестовых файлов в файлы классов. Таким образом, классы получают также способности, которые предназначены только для тестирования. Мне нравится это до сих пор, чувствует себя чистым. Я (пока) не создаю библиотеку для тестирования, которая совместно используется двумя внешними интерфейсами тестирования, этот код был передан в файл класса объекта, который сейчас проверяется.
Обратите внимание, что мои комментарии ниже подписаны "user89021", но это я, karlthorwald. Я ничего не могу с этим поделать.