Модульное тестирование сторонних ORM

Question

Я прочитал несколько тем на SO о полезности модульного тестирования различных приложений. Мнения могут варьироваться от «все время тестировать» до «модульные тесты бесполезны» и все что между ними («тест, где это имеет смысл»). Я склоняюсь к среднему.

Это подводит меня к моему вопросу. Я пытаюсь решить, было бы полезно или целесообразно провести базовые юнит-тесты ORM сторонних разработчиков, как это предлагается в этом посте SO: текст ссылки

некоторые базовые тесты могут быть полезны в качестве страховки от будущих переломных изменений, в зависимости от того, как вы используете инструмент. Например, вместо макетирования всей n-уровневой цепочки (я не фанат насмешек, когда в этом нет необходимости), просто используйте инструмент ORM для создания, чтения, обновления и удаления типичного объекта / записи и проверьте операцию, используя прямые операторы SQL в (тестовой) базе данных. Таким образом, если сторонний поставщик позже обновляет что-то, что нарушает основные функциональные возможности, о которых вы будете знать, и новые разработчики вашего проекта могут легко увидеть, как использовать инструмент ORM из примеров модульного тестирования.

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

1. ORM, который мы используем, требует, чтобы статический объект (ы) источника данных был создан и зарегистрирован на уровне доступа к данным и связан с аутентифицированным пользователем. Это потребует большой настройки теста и, вероятно, будет проблематично на сервере сборки, где ни один пользователь не вошел в систему.
2. Производитель ORM имеет довольно хороший опыт выпуска новых обновлений и не нарушает базовых функций. Более того, всякий раз, когда приходит время обновить ORM до последней версии, я представляю, что приложение не будет запущено непосредственно в производство, но в любом случае будет подвергнуто тщательному регрессионному тестированию.
3. Ведение тестовой базы данных для модульного тестирования является проблематичным в этой среде. Тестовая БД стирается после каждого основного выпуска и заменяется резервной копией БД из промежуточной стадии с обфусцированными чувствительными данными. Я хотел бы представить, чтобы иметь тестовую базу данных для модульного тестирования ORM, нам нужно было бы запустить несколько сценариев / кода, которые бы переводили базу данных в «тестовое» состояние. Снова слишком много настроек и обслуживания.
4. И, наконец, документация / помощь ORM для новых разработчиков. Я вижу, как что-то подобное может быть полезным. Но поставщик ORM предоставляет довольно хорошую документацию / помощь с демонстрационными приложениями. Таким образом, написание модульных тестов в дополнение к этому, похоже, не стоит всех усилий.

Итак, стоит ли проходить через все эти неприятности, просто чтобы убедиться, что ORM делает то, что должен делать (что такое CRUD)? Разве это не обязанность продавца?

Answer 1

Вы сказали это сами. Проверьте, где это имеет смысл. Если вам будет легче испытать сторонний ORM, то сделайте это. Но, в конечном счете, вы доверяете их инструменту. Что вы будете делать, если ORM внезапно перестанет работать? Вы написали достаточно кода против этого, что вы не можете легко вырвать его? Вы бы подождали, пока они это исправят.

По сути, вы должны рассматривать сторонние инструменты как пресловутые черные ящики и позволять им делать то, что вы их купили. По этой причине вы заплатили деньги, которые сделали, верно? Чтобы не писать самому.

Answer 2

Поставщик несет ответственность за то, чтобы ORM делал то, что он должен делать, но вы несете ответственность за то, чтобы ваше приложение делало то, что оно должно делать, и если по какой-то причине оно не получится, ваши клиенты будут недоволен, даже если это "просто", потому что ORM не удалось.

Ваши тесты могут гарантировать, что ORM работает так, как вы ожидаете, учитывая то, как вы его называете. Вполне возможно, что ORM изменится так, чтобы не было «сломано», но это не очень подходит для вашего приложения.

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

Answer 3

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

И да, я считаю, что это ответственность поставщика. Я ожидаю (и предполагаю), что их вещи работают. Вот как я отношусь к своим поставщикам.

Answer 4

Проверка того, что сторонняя библиотека ORM выполняет свою работу, вовсе не является модульным тестированием. Однако не в этом суть вашего вопроса.

Как уже неоднократно говорилось в таких книгах, как «Эффективная работа с устаревшим кодом» Майкла Фезерса или «Доменно-управляемый дизайн» Эрика Эванса или «Чистый код» Роберта Мартина, ваша сторонняя библиотека ORM является технической деталью который должен быть абстрагирован от вашей кодовой базы, именно потому, что вы по определению не имеете никакого контроля над сторонними библиотеками. Если они изменятся, вы согласитесь.

Таким образом, ваше решение - создать оболочку для этой библиотеки ORM, опубликовав идеально связанный с доменом интерфейс для остальной части вашего приложения, но общий интерфейс, вероятно, тоже подойдет. Эту оболочку вам нужно протестировать с помощью полнофункциональных автоматических тестов, которые неизбежно должны настроить ваше приложение вместе с базой данных и всей необходимой для нее конфигурацией и подготовкой. Эти тесты не на уровне единиц и, как ожидается, будут очень медленными.

Вы можете прочитать о различных уровнях тестов и о том, как они должны быть установлены в главе 6 книги «Непрерывная интеграция» Пола М. Дювалля.

При написании истинных тестов на уровне модулей для вашего уровня приложения вы высмеиваете оболочку над библиотекой ORM, что вы можете сделать, потому что вы контролируете код оболочки.

Это стандартная практика. Очевидным преимуществом этого является то, что когда вы решите обновить библиотеку ORM или (что весьма возможно), когда ваш клиент / начальник решит переключиться на другую ORM или базу данных, с которой данный ORM не совместим, вы получите мгновенный отзыв о ошибки регрессии в тестах вашей оболочки, и все, что вам нужно сделать, это приспособиться к изменениям внутри вашей оболочки.

Кстати, «слишком большая нагрузка на обслуживание» - это ошибка, вызванная отсутствием автоматизации.

Answer 5

Лично я считаю, что реальные модульные тесты должны проверять только само приложение, а все, что необходимо развернуть и настроить отдельно, должно быть смоделировано.

То, что вы говорите, - это написать несколько интеграционных / функциональных тестов, которые тестируют всю систему полностью. Они никогда не будут легкими, но, вероятно, все еще полезны в некоторых случаях (например, если ваша система не слишком сильно меняется и в то же время критична для вашей компании). Я также видел такие тесты, автоматизированные, использующие виртуальные серверы (либо VMWare, либо эквивалент Microsoft), а также пример базы данных, которая восстанавливалась из файла перед каждым запуском теста. Вы также можете просто установить ORM один раз и принять, что тесты не пройдут в основном из-за того, что конфигурация будет нарушена. Очевидно, что вы можете протестировать больше, но имейте в виду, что стоимость выше.