Используя PowerMock или Насколько Вы позволяете своим тестам влиять на Ваш дизайн? [закрытый]

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

основная мотивация мы имеем для использования PowerMock, при использовании стороннего кода, который препятствует тому, чтобы код был тестируемым. Хорошая альтернатива использует anti-corruption-layer, который абстрагирует сторонний код и делает его тестируемым. Однако иногда я думаю, что код является более чистым просто использование стандартных API. Хорошим примером этого является Java ME API. Это полно вызовов статического метода, которые предотвращают поблочное тестирование.

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

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

(основатель PowerMock)

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

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

Только можно предотвратить запахи кода.

У нас были многие из тех же вопросов, возникают на арене.NET, относительно Изолятора Typemock. См. Это сообщение в блоге

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

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

(я работаю в Typemock, но был однажды против него)

Я категорически не согласен с этим вопросом.

Нет никаких оснований для насмешливого инструмента, ограничивающего выбор дизайна. EasyMock, EasyMock Class Extension, jMock, Mockito и другие исключают не только статические методы. Эти инструменты также не позволяют вам объявлять классы и методы final , и это само по себе очень плохо. (Если вам нужен авторитетный источник, защищающий использование final для классов и методов, см. Книгу «Эффективная Java» или эту презентацию автора.)

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

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