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