Jmock насмехается над статическим методом

Powermock - это расширение EasyMock, которое позволяет имитировать статические методы.

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

JMockit - еще один инструментарий, который позволяет имитировать статические методы (а также методы final, конструкторы и т. д.).

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

Например, один шаблон / идиома, который мне нравится использовать, - это статический фасад, в частности, чтобы предоставить более простой и легкий в использовании API для подсистемы сохраняемости в бизнес-приложении. На мой взгляд, нет другого решения более элегантного, чем что-то вроде:

    List<Person> peopleAboveAge = 
        find("select p from Person p where p.age >= ?", age);

где метод find статически импортируется из класса PersistenceFacade, который определяет только статические методы и инкапсулирует, как получить соответствующий экземпляр Session / EntityManager. Это гибкое и удобное решение для модульного тестирования. Я использовал его в бизнес-приложении, в котором было более 500 постоянных сущностей, использующих Hibernate. Статический фасад помог, когда мы перешли с Hibernate 2 на Hibernate 3, когда мы перешли с Oracle на Sybase, а затем обратно на Oracle, и когда мы начали использовать аннотации JPA вместо файлов «hbm.xml» для сопоставления ORM.