jmock насмешливый статический метод

Question

У меня есть статический метод в моем коде, который я хотел бы как-то издеваться.

Я использую jmock.

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

Я собираюсь сделать это неправильно?

ОБРАТНАЯ СВЯЗЬ:

Я собирался иметь интерфейс и класс, который должен был метод, который просто называемый статический метод. Это позволило бы мне высмеять логику, просто издеваясь над вызовом этого класса-оболочки. (Я чувствую себя грязным, даже об этом говорю :))

Answer 1

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

Answer 2

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

Answer 3

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

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

Например, один шаблон/идиом, который мне нравится использовать, - это статический фасад , в частности, для упрощения и упрощения использования 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.