mock-oder stub-bei verketteten aufrufen

protected int parseExpire(CacheContext ctx) throws AttributeDefineException {
    Method targetMethod = ctx.getTargetMethod();
    CacheEnable cacheEnable = targetMethod.getAnnotation(CacheEnable.class);
    ExpireExpr cacheExpire = targetMethod.getAnnotation(ExpireExpr.class);
    //check for duplicate setting
    if (cacheEnable.expire() != CacheAttribute.DO_NOT_EXPIRE && cacheExpire != null) {
        throw new AttributeDefineException("expire are defined both in @CacheEnable and @ExpireExpr");
    }
    //expire time defined in @CacheEnable or @ExpireExpr
    return cacheEnable.expire() != CacheAttribute.DO_NOT_EXPIRE ? cacheEnable.expire() : parseExpireExpr(cacheExpire, ctx.getArgument());
}

ist die Methode zu testen , 

Method targetMethod = ctx.getTargetMethod();
CacheEnable cacheEnable = targetMethod.getAnnotation(CacheEnable.class);

Habe ich zu verspotten drei CacheContext,Methode und CacheEnable.
Gibt es irgendeine Idee, um den test-Fall viel einfacher?

InformationsquelleAutor der Frage jilen | 2011-10-28

  1. 103

    Mockito behandeln können verkettet stubs:

    Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

//note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

//note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

    AFAIK die erste Methode in der Kette gibt ein mock, die eingerichtet ist, um Ihr Wert in der zweiten verketteten Methodenaufruf.

    Mockito Autoren beachten Sie, dass dies sollte nur verwendet werden, für legacy-code. Eine bessere Sache zu tun ist, schieben Sie das Verhalten in Ihre CacheContext und bieten alle Informationen, die es braucht, um den job selbst. Die Menge der Informationen, die Sie sind, ziehen aus CacheContext deutet darauf hin, dass Ihre Klasse feature-Neid.

    InformationsquelleAutor der Antwort Lunivore

  2. 3

    Fand ich JMockit einfacher zu bedienen und wechselte zu es völlig. Siehe test cases mit:

    https://github.com/ko5tik/andject/blob/master/src/test/java/de/pribluda/android/andject/ViewInjectionTest.java

    Hier habe ich die mock-Weg-Aktivität Basis-Klasse, kommt von Android SKD und vollständig
    gekürzte. Mit JMockit können Sie mock thingis tha sind final, private, abstract, oder was sonst.

    In Ihrem Testfall würde das so Aussehen:

    public void testFoo(@Mocked final Method targetMethod, 
                    @Mocked  final CacheContext context,
                    @Mocked final  CacheExpire ce) {
    new Expectations() {
       {
           //specify expected sequence of infocations here

           context.getTargetMethod(); returns(method);
       }
    };

    //call your method
    assertSomething(objectUndertest.cacheExpire(context))

    InformationsquelleAutor der Antwort Konstantin Pribluda

  3. 3

    Mein Vorschlag, um Ihren test-Fall-einfacher ist es, umgestalten Methode.

    Anytime ich finde mich mit Mühe Prüfung eine Methode, es ist ein code smell ist für mich, und ich Frage warum ist es schwer zu testen. Und wenn der code ist schwierig zu testen, ist es wahrscheinlich schwer zu bedienen und zu warten.

    In diesem Fall ist es, da haben Sie eine Methode, die Kette, die geht mehrere Ebenen tief. Vielleicht pass in ctx, cacheEnable, und cacheExpire als Parameter.

    InformationsquelleAutor der Antwort Doug R

Schreibe einen Kommentar