Стоимость установки тестов в JUnit - использование макетов объектов по сравнению с тестами репозитория в устаревшем коде - PullRequest
0 голосов
/ 08 июня 2018

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

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

Большая часть старого кода настраивает свои тестовые данные с помощью компоновщикови тестовые утилиты, которые в свою очередь используют репозиторий.Поскольку домен довольно сложный, это часто включает в себя настройку достаточного количества объектов и того, как они связаны друг с другом.Поэтому переписывание класса тестов (скажем, ~ 15 тестов) с использованием только имитируемого объекта может занять довольно много времени.И, как и везде, время не является бесконечным ресурсом.

Если мы добавим некоторую новую функциональность в класс, было бы гораздо проще просто написать один новый тест репозитория (в дополнение к существующим 15), чемчтобы выяснить, как именно нужно настроить тестовые данные, используя различные фиктивные объекты.

Я попытался найти некоторую информацию о том, как и в какой степени настройка теста влияет на фактическое время, необходимое для запускатесты, но я не смог найти никакой полезной информации.Мои единственные "факты" - это наблюдения, которые я делаю, когда провожу тестовый класс.Тестовая настройка для репо-теста может легко занять ~ 10 секунд, в то время как тестовая настройка для тестового класса запускается менее чем за секунду.

ПРИМЕЧАНИЕ. Я знаю, что могу использовать секундомер JUnit для тестирования производительностиодин или набор тестов, но мой вопрос больше касается лучших практик, чем того, сколько именно времени у меня уходит на выполнение тестов.

У меня два вопроса:

  1. Допустим, я столкнулся с тестовым классом, в котором уже есть 15 модульных тестов, где ни один из них не издевается над поведением.Я пишу тест и делаю небольшое исправление в классе.У меня нет времени переписать весь тестовый класс для макетов объектов.Должен ли я просто добавить новый тест, не издеваясь над поведением, и следовать существующему (и плохому) шаблону?Действительно ли имеет значение, есть ли у меня 15 немодальных тестов и 1 фиктивный тест, или если у меня есть 16 немодулированных тестов?

  2. В моем классе с 15 модульными тестами некоторые изтесты легче проводить рефакторинг, чем другие.Стоит ли переписывать только пять тестов с использованием поддельных объектов?Это противоречит передовому опыту или каким-либо другим образом нехорошо иметь тестовый класс, в котором некоторые тесты используют макеты, а некоторые нет?

Ответы [ 2 ]

0 голосов
/ 09 июня 2018

Как написано @ShanuGupta, на ваш вопрос нет общего ответа.

Но вот моя мысль:

После правильности читаемости является вторым наиболее желательным значением кода, особенно тестового кода (поскольку это исполняемая спецификация )

С другой стороны, не существует правила, согласно которому единица не может иметь более одного тестового класса.,Поэтому я бы отделил «старые» методы тестирования, не использующие mocks, от «mocking» тестов, поместив их в отдельные классы тестирования.

0 голосов
/ 08 июня 2018

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

Должен ли я просто добавить новый тест, не издеваясь над поведением, и следовать существующему (и плохому) шаблону?Действительно ли имеет значение, есть ли у меня 15 немодальных тестов и 1 фиктивный тест, или если у меня есть 16 немодальных тестов?

Это не просто один новый тест.Если вы все еще пишете в плохом / медленном режиме, вы просто увеличиваете технический долг.Вы должны сами изложить лучшие практики написания новых модульных тестов.

В моем классе с 15 модульными тестами некоторые тесты легче реорганизовать, чем другие.Стоит ли переписывать только пять тестов для использования макетов?

Абсолютно.Почему бы и нет?Вы сами говорите об улучшениях, которые вы получаете, следуя более новому стилю кода.

Это противоречит передовому опыту или иным образом нехорошо иметь тестовый класс, в котором некоторые тесты используют макетыа некоторые нет?Хорошо, одна из лучших практик - везде иметь согласованный код.Сочетание старых и новых репозиториев с макетами не слишком хорошо подходит для лучших практик.Но я был бы более обеспокоен, если код, который вы пишете, не очень хорошо покрыт юнит-тестами, в каком бы стиле он ни был.

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

...