Я нахожусь в процессе написания насмешливого слоя поверх нашего существующего API-интерфейса Db (его нельзя изменить, к сожалению). Сначала я представляю себе макеты, которые специфичны для определенных табличных функций - просто озабочены именами таблиц.
when(mockDbApi.query(argThat(new TableNameMatcher("table1")))).thenReturn(result);
Где функция запроса принимает аргумент QueryDescriptor. Мой класс TableArgumentMatcher находится ниже:
public static class TableNameMatcher extends ArgumentMatcher<QueryDescriptor> {
private String tableName;
public TableNameMatcher(String tableName) {
this.tableName = tableName;
}
@Override
public boolean matches(Object argument) {
if (argument instanceof QueryDescriptor) {
QueryDescriptor qDescript = (QueryDescriptor) argument;
return qDescript.getBaseTable().equals(tableName);
}
return false;
}
}
Пытаясь это, я заканчиваю дампом исключения (фреймворк хорош, и пользовательский рендеринг трассировки стека для меня):
org.mockito.exceptions.misusing.InvalidUseOfMatchersException
org.mockito.exceptions.misusing.InvalidUseOfMatchersException:
Misplaced argument matcher detected here:
at com.company.CommonsTestDb.mockQuery(CommonsTestDb.java:88)
You cannot use argument matchers outside of verification or stubbing.
Examples of correct usage of argument matchers:
when(mock.get(anyInt())).thenReturn(null);
doThrow(new RuntimeException()).when(mock).someVoidMethod(anyObject());
verify(mock).someMethod(contains("foo"))
В строке 88 CommonsTestDb я делаю то же самое, когда (), как я перечислил выше. Обратите внимание, что код компилируется чисто и не предупреждает меня о каких-либо проблемах типа.
Мысли? Я вижу много примеров перенаправления отдельных лиц для использования возможностей захвата и проверки соответствия позже, однако я не думаю, что это уместно, поскольку их может быть несколько, когда предложения для различных таблиц.
Спасибо