Как издеваются возвращаемое значение из чтения файла свойств в тесте JMock

Question

У меня есть одноэлементный ява свойства класса (RepositoryProperties.java), который считывает из текстового файла, чтобы получить значение, возвращаемое методом readFromSql:

public boolean readFromSql() { 
    String lPhase = getPilotProfileDatabaseTransitionPhase(); 
    if (lPhase.equals("PHASE_ONE_SQL")) { 
     return true; 
    } else 
     return false; 
} 

Затем, когда я хочу, чтобы добавить запись через мой репозиторий класса реализации, я должен проверить это значение, чтобы узнать, какой блок кода для выполнения:

if (RepositoryProperties.getInstance().readFromSql() 
     { 

.. если это правда, записать данные в SQL, иначе пропускать этот блок

Теперь мне нужно добавить модульный тест Jmock для моего метода добавления репозитория, чтобы метод readFromSql возвращал true (другой тест проверяет значение false), не внося никакого отношения к текстовому файлу. Я боюсь, что jmock для меня совершенно новый, и я не могу понять, как издеваться над значением, возвращаемым readFromSql. У меня нет метода сеттера.

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

myMockContext.checking(new Expectations() { 
{ 
     RepositoryProperties.getInstance().readFromSql(); 
     will(returnValue(true)); 

бы реально оценить мало указаний о том, как делать это правильно и где.

Answer 1

JMock, как правило, разработан вокруг идеи насмешек экземпляров интерфейсов. Вы можете получить его, чтобы издеваться над экземплярами классов, хотя это не рекомендуется. То, что вы пытаетесь сделать, - это еще больше - вы хотите издеваться над статическим методом. Это очень против философии JMock, и Jmock будет сражаться с вами на каждом шагу. Возможно, вам захочется взглянуть на альтернативные издевательские рамки, такие как PowerMock и Mockito, которые имеют большую гибкость при использовании mocks в ситуациях, когда у вас нет четкого тестового шва (например, инъецированного интерфейса).

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