Как организовать живые тесты целостности данных и тесты элемента кода?

У меня есть несколько файлов с кодом, тестирующим код (который использует "unittest" класс).

Позже я нашел, что будет хорошо протестировать целостность БД также. Я поместил это в отдельное дерево каталогов. (Вещи как ключи имеют правильный формат, родительские и дочерние узлы указывают правильно и такой.Править: это - nosql проект, где я не могу полагаться на проверки уровня базы данных liek ссылочная целостность и такой.)

Я использую тот же unittest класс для проверок целостности.

Теперь интересно, имеет ли это действительно смысл разделить это. Протестировать целостность данных I часто запасных деталей кода, который я использую для тестирования кода, который обрабатывает данные.

Но это не то же. Код тестирует тестовые базы данных использования (который удален после каждого теста), и проверки целостности соединяются с живыми данными и анализируют их. Проверки целостности, которые я хочу назвать от крона и отправить предупреждение, если что-то происходит в живой базе данных.

Как Вы обработали бы это? Есть ли стандарты для такой установки? Каков Ваш опыт?

Моя тенденция состоит в том, чтобы поместить все в тот же файл, который привел бы к тестам кода также быть выполняемым кроном на продуктивной среде.

Править: То, что также управляет мной, должно попытаться сохранить проект простым а не иметь слишком много файлов, затронутых единственной задачей или рабочим процессом. Без всего тестирования у меня уже есть файл класса, подкласс, связанный класс, некоторая библиотека (помощник) файлы и основной код. Тестирование добавляет один файл. Это помогает мне сохранить свое внимание сфокусированным при кодировании, это меньше подчеркивает, и я полагаю, что совершаю меньше ошибок, и я могу быстрее помнить и найти, что определенный код расстается с меньшим количеством затронутых файлов. Только один файл тестирования на рабочий процесс помог бы здесь. Если я сохраняю это отдельным существует 2 файла (тестирование целостности данных и тестирование кода) и возможно 3 (общая библиотека для обоих). Абстракция добавила бы сложность.

Edit2: Я теперь осуществляю рефакторинг немного и только перемещаю файлы тестирования данных в то же дерево каталогов где также код, тестирующий жизни, но сохраняющий различные файлы с указанием имени "целостность" или "тестированием". Я еще не объединю файлы, потому что 2 человека рекомендовали против него, и я верю, по их опыту, и совет на данный момент. Я буду жить с дублированием кода в настоящий момент.

Edit3: Я забыл упоминать, что выбор тестов на выполнение не определяется древовидной структурой в этом случае. Тесты перечисляются в основном файле, таким образом, у меня есть 2 основных файла "целостность" и "код, тестирующий" в данный момент, и тест может жить в той же directury структуре.

Возможно, больше людей ответит. Спасибо до сих пор за ценный вклад, который уже помогает мне разработать заключительную структуру!

Edit4: Я сделал больше рефакторинга теперь. Кажется, что я должен сохранить 2 файла, но с немного измененной целью. Один предназначенный для запланированного контроля на рабочем сервере. И другой для разработки. Но в обоих файлах может быть проверки целостности или кодировать тесты. И в обоих файлах операции могут быть выполнены на тестовых базах данных (которые стираются после теста) и на постоянной базе данных (у каждого есть постоянная база данных, рабочий сервер и develpment сервер). И одна важная вещь: Я перемещаю много общего кода от файлов тестирования до файлов класса. Таким образом, классы получают также способности, которые являются для тестирования только. Мне нравится это до сих пор, чистые чувства. Я еще не создаю библиотеку для тестирования, которое совместно используется 2 тестированиями frontends, этот код перешел к файлу класса obejct, который является teted на данный момент.

Обратите внимание на то, что мои комментарии ниже подписываются с "user89021", но это - я, karlthorwald. Я ничего не могу делать с этим.