EasyMock: пустые методы
date; date --date="5 hours ago 55 minutes ago 40 seconds ago " +%H%M-%d%m%Y
Таким образом, вы можете добавлять или вычитать из текущего времени
3 ответа
Если я понимаю, что вы хотите делать правильно, вы сможете использовать andAnswer () :
mockObject.someMethod(eq(param1), eq(param2));
expectLastCall().andAnswer(new IAnswer() {
public Object answer() {
//supply your mock implementation here...
SomeClass arg1 = (SomeClass) getCurrentArguments()[0];
AnotherClass arg2 = (AnotherClass) getCurrentArguments()[1];
arg1.doSomething(blah);
//return the value to be returned by the method (null for void)
return null;
}
});
В Руководстве пользователя EasyMock объясняется :
Создание возвращаемых значений или исключений
Иногда нам нужно, чтобы наш фиктивный объект возвращал значение или генерировал исключение, которое создается во время фактического вызова. Начиная с EasyMock 2.2, объект, возвращаемый
expectLastCall ()иexpect (значение T), предоставляет методandAnswer (ответ IAnswer), который позволяет [вам] указать реализация интерфейсаIAnswer, который используется для создания возвращаемого значения или исключения.Внутри обратного вызова
IAnswerаргументы, переданные в фиктивный вызов, доступны черезEasyMock.getCurrentArguments (). Если вы их используете, такие рефакторинги, как изменение порядка параметров, могут нарушить ваши тесты. Вы были предупреждены.
Если вы просто вызываете метод void каждый раз, когда ожидаете его вызова, а затем вызываете EasyMock.expectLastCall () перед вызовом replay ( ) , Easymock будет «запоминать» каждый вызов.
Поэтому я не думаю, что вам нужно явно вызывать expect () (кроме lastCall ), поскольку вы ' re не ожидает ничего от метода void, кроме его вызова.
Спасибо, Крис!
«Удовольствие с EasyMock» от коллеги по StackOverflow Берт Беквит - хороший пост в блоге, который предоставляет больше подробно. Примечательная выдержка:
В основном поток, который я обычно использую, выглядит так:
- Создайте фиктивный
- вызов
expect (mock. [Вызов метода]). AndReturn ([результат])для каждого ожидаемый вызов- вызов
макет. [вызов метода], затемEasyMock. expectLastCall ()для каждого ожидаемого недействительного вызова- call
replay (mock)для переключения из режима «записи» в режим «воспроизведения»- вводить имитацию по мере необходимости
- вызывать тестовый метод
- call
verify (mock), чтобы убедиться, что все ожидаемые вызовы произошли
В подобных ситуациях я обнаружил, что создание вложенного класса в моем классе модульного тестирования и переопределение методов с особыми требованиями таким образом - лучший путь. Поэтому, если вы тестируете ClassA , у которого есть этот метод с параметрами, к которым вам нужно получить доступ, вы должны сделать что-то вроде:
class MockClassA extends ClassA {
@Override
void specialMethod(String param1, String param2) {
// do logging or manipulation of some sort
super.specialMethod(param1,param2); // if you need to
}
}
В моем коде модульного тестирования я просто использую вместо этого этот экземпляр. Просто относитесь к нему как к любому другому фиктивному объекту. Намного проще, чем смешивать библиотеки, что, я согласен, вероятно, не лучшая идея.