Вот о том и речь... Mock - болванка, заглушка. Позволяет внутри unit теста очень быстро написать реализацию интерфейса (или класса) с требуемым тебе поведением. JMock полностью совместим с JUnit и дополняет его.

Пример использования.

Предположим, что у нас есть интерфейс ICollaborator с описанием единственного метода executeJob, возвращающего строковое значение:

И есть класс ServiceClass с единственным методом runService. В качестве аргумента метод принимает реализацию интерфейса ICollaborator и сравнивает возвращаемое методом executeJob строковое значение со строкой "success". В случае совпадения значений возвращается истина, иначе - ложь.

Что делать, если нам необходимо протестировать класс ServiceClass, но при этом писать реализацию интерфейса ICollaborator рано? Вот в таком случае нам может пригодиться JMock.

Создадим тестовый класс, и перво-наперво надо с помощью аннотации org.junit.runner.RunWith указать, что тест будет запускаться с помощью класса JMock, полностью совместимого с JUnit4.

Затем нужно создать фабрику - объект Mockery. Следующим этапом будет создание болванки, являющейся "как бы" реализацией интерфейса ICollaborator.

Далее необходимо настроить поведение болванки. Сначала дам код, потом только прокомментирую его

Тут с непривычки можно рехнуться, если честно! Явадок на JMock подробными комментариями не радует, поэтому за консультацией отправляю на сайт www.jmock.org, где можно найти достаточно информации по синтаксису Expectations (ожиданий). Кстати, синтаксис "ожиданий" очень похож на конструкции языка программирования Perl, такое вот ИМХО...

Метод checking навешивает на болванки требуемые нами expectations - удачное, кстати, слово. Ожидания - это то поведение, которое мы ожидаем от новоиспечённых болванок.

Метод one() принимает объект - болванку и возвращает его (объекта) как бы настоящий класс, чьи методы теперь можно вызывать, чем мы и воспользуемся. Мы "ожидаем", что будет вызван метод executeJob(). Потом метод должен (will) вернуть (returnValue) строку "success". One() подразумевает, что метод executeJob будет вызван в ходе теста ровно один раз, не больше и не меньше.

Далее код повторяется с той лишь разницей, что возвращаемым значением будет строка "failure". Для чистоты эксперимента, так сказать.

Теперь болванку collaborator можно с чистой совестью применять в данном тесте. Ограничения - должно быть ровно два вызова executeJob(), они будут возвращать разные значения. Ограничения можно сделать и не такими жёсткими, возможности работы с JMock на самом деле очень велики, охватить все его возможности в одной статье не представляется возможным. Главное - понять предназначение библиотеки и её основные концепции, а там уже можно накручивать любые конструкции ожиданий, какие только представить можно!

Ну что, тест!

Зелёная полоска - успех! Класс ServiceClass отработает с классами, реализующими интерфейс ICollaborator, именно так, как было задумано.

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

Пример теста взят с сайта www.ibm.com. Статья изрядно устарела - потребовалось немало поскрипеть мозгом, чтобы привести выложенный там код в рабочее состояние. Плюс ко всему, JMock уже позволяет тестировать реализации классов, не имеющих конструкторов с пустыми аргументами. Так что особой надобности в RMock, также описанном в статье, я не рассмотрел.

Вроде много написал... на ФАК, кажется, не тянет, хотя это на усмотрение модераторов.

Под интерфейсом я имел в виду гуй. 

Это я не догнал...  

Гуй тестить тяжко, согласен.