В чем разница между полным насмешкой и частичным насмешкой?

Question

В настоящее время я работаю с издевательством с Mockito с помощью jUnit, и я наткнулся на раздел Partial Mocking, в котором вы используете Mockito.spy до , частично издеваетесь над объектом. Кажется, я не понимаю эту концепцию , частичный издевательство, так как я не могу найти сценарий, почему я должен использовать его (поскольку он довольно похож на насмешку вообще).

Может ли кто-нибудь объяснить, как частичная насмешка отличается от обычной насмешки? И если возможно, любезно предоставите примеры.

Спасибо!

Answer 1

Частичное издевательство - это то, где вы берете класс и просите его вести себя как обычно, за исключением того, что вы хотите переопределить определенные функции. Это полезно для служб модульного тестирования, которые общаются с другими частями вашего приложения. Переопределяя поведение, которое вызовет другую часть вашего приложения, вы можете протестировать свою службу изолированно.

Другим примером может быть тот факт, что компонент связывается с драйвером базы данных. Издеваясь над частью, которая будет связываться с драйвером, вы можете протестировать эту часть приложения, не имея базы данных.

Answer 2

От EasyMock 2.2 classextension documentation:

Иногда вам может понадобиться, чтобы дразнить только некоторые методы класса и держать нормальное поведение других. Обычно это происходит, когда вы хотите, чтобы проверял метод, который вызывает некоторые другие в том же классе. Таким образом, вы хотите, чтобы сохраняли нормальное поведение тестируемого метода и издевались над другими.

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

Частичное издевательство может быть очень удобным, но я стараюсь избегать его как можно больше.

Answer 3

Частичное издевательство: Скажем, у вас есть класс, который имеет 10 + параметров для конструктора (это никогда не должно происходить, но в этом примере можно сказать, что это так), это настоящая задача создать этот объект целиком. Рамки, такие как mockito, позволяют вам просто использовать части объекта, который вы действительно хотите протестировать. , например

@Mock BigClass big; //contains loads of attributes

...

when(big.getAttributeOneOfTwenty()).thenReturn(2); //these are static imports from mockito

Answer 4

я считаю полезным, когда я вынужден работать с API, опираясь на наследование от абстрактных классов и/или унаследованного кода, работающих с nonmockable статических классов (один реальный пример - DAO).

Частичное издевательство (в смысле использования средства шпиона от Mockito) позволяет вам обманывать вызовы унаследованным методам в первом случае или обертывать вызовы статическим методам, которые вы вынуждены использовать в обычных методах, которые вы можете издеваться, проверять и т. д.

Как правило, вы должны проектировать и писать код таким образом, чтобы вам не понадобилось это (инъекция зависимости, отдельная ответственность за класс и т. д.). Но время от времени это полезно.

быстрый и грубый пример, чтобы визуализировать статический пример API:

class BigUglyStaticLegacyApi { 
    public static Foo someStaticMethodFetchingFoo() {...} 
} 

class Bar { 

    public void someMethodYouTest() { 
     Foo foo = getFoo(); 
     //do something with Foo (a FooBar, for example :)) 
    } 

    /*this one you mock via spying - not the most elegant solution, 
    but it's better than nothing */ 
    @VisibleForTesting 
    protected Foo getFoo() { 
     return BigUglyStaticLegacyApi.someStaticMethodFetchingFoo(); 
    } 
} 

Answer 5

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