Единичное тестирование стороннего ORM

Question

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

Это приводит меня к моему вопросу. Я пытаюсь решить, будет ли это полезно или практично, чтобы иметь некоторый базовый юнят-тесты тестирования 3 участника ОРМ, как предложено в этом SO сообщении: link text

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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