Кто-нибудь должен использовать методы и классы библиотек модульного тестирования в живой среде разработки?

Question

Этот вопрос выглядит странно или вообще может быть бессмысленным. Недавно я просматривал некоторый код на языке Java, где разработчик использовал один из методов из библиотеки модульного тестирования «org.easytesting». Пример: он использовал метод "Strings.isNullOrEmpty" класса "Strings" из этой библиотеки, чтобы проверить необнуляемость некоторых значений, и использовал другие классы / методы в других местах кода.

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

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

Answer 1

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

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

Answer 2

Не обращая особого внимания на библиотеки тестов, вот ответ на этот более общий вопрос:

Следует ли вам использовать вспомогательные классы общего программирования, предоставляемые какой-либо платформой или библиотекой? (Например, если вы используете StringUtils / CollectionUtils / etc, предоставляемый фреймворком web / UI / logging / ORM / ...).

Аргументы других ответов по-прежнему в основном верны даже в этом более общем случае. Вот еще немного:

• Эти утилиты были разработаны специально для использования фреймворком. Скорее всего, они содержат только очень специфические методы с узкими вариантами использования (те, которые на самом деле требуются платформой) и ничего более. Они могут быть оптимизированы для конкретного внутреннего поведения платформы, а не для общих целей.
• Разработчики фреймворка могут вносить серьезные изменения, не задумываясь, так как они не ожидают, что многие пользователи выйдут за их рамки.
• Было бы тревожно видеть импорт, например, из библиотека пользовательского интерфейса в вашем внутреннем коде, она выглядит как запах кода.
• В модульных проектах вам не нужно вводить дополнительные зависимости в утилиты фреймворка (опять же, зависимость от UI-фрейма от ваших внутренних модулей - это запах кода). Это также добавило бы кучу ненужных транзитивных зависимостей, которые могут быть даже несовместимы с другими зависимостями.

Поэтому я бы сказал, что в общем случае вы не должны использовать утилиты фреймворков, за исключением тех мест, где вы на самом деле работаете с этими фреймворками. Но даже тогда вы должны рассмотреть вопрос об использовании Apache Commons, Guava и т. Д. Для согласованности.

Теперь вы также можете заменить термины UI и back end на test и production в последних двух точках. Тестовые фреймворки также особенные в том смысле, что вы обычно не включаете их в качестве зависимости во время выполнения. Поэтому вам необходимо изменить область действия тестовых зависимостей, чтобы сделать их доступными во время выполнения. Вам следует избегать этого по причинам, указанным в последнем пункте.

Answer 3

Можно утверждать, что библиотека модульных тестов - это всего лишь библиотека, но я не вижу ее в таком виде.

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

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

Наконец, код должен сообщать о намерениях. Это включает в себя включает в себя (каламбур). Разработчик не намеревался писать код модульного тестирования, но именно об этом сообщит включение библиотеки модульного тестирования.