2015-09-26 11 views
9

Należy rozważyć następującą próbkę MockUp klasy Foo, która przechwytuje w konstruktorze Bar, a następnie implementuje toString() pod względem Bar;Czy JMockit MockUp mock toString()?

public class FooStub extends MockUp<Foo> { 

    private Bar bar; 

    @Mock 
    public void $init(Bar bar) { 
     this.bar = bar; 
    } 

    @Mock 
    public String toString() { 
     return bar.toString(); 
    } 
} 

Jeśli Foo stanie przesłonić toString() wszystko działa poprawnie. W przeciwnym razie otrzymasz numer IllegalArgumentException: "Nie znaleziono prawdziwych metod dla poniższych prób". Rozumiem stąd, że JMockit nie wygląda w klasach bazowych i dlatego nie może znaleźć metody, którą można udawać.

Zakładając, że nie mogę zmodyfikować klasy Foo (w rzeczywistości mogę, ale tylko ze względu na argument), czy jest jakiś sposób na kpiny z toString() tylko dla tej klasy Foo?

Dla jasności, chcę wyśmiać wszystkie wystąpienia tej klasy, a nie tylko jedno wystąpienie (które ma proste rozwiązania, które nie wymagają MockUp).

+2

Możliwy duplikat [Jmockit: Nie można pozorować metody naString klasy net.android.Uri] (https://stackoverflow.com/questions/41561351/jmockit-cant-mock-method-tostring-of-net- android-uri-class) – Jotunacorn

Odpowiedz

0

JMockit będą drwić wszystkie super-klasy w górę hierarchii klasowej do, ale z wyłączeniemjava.lang.Object.

Można zdefiniować private final klasę w teście, który rozciąga Bar nadrzędnymi toString() który deleguje do Bar „s toString() dzwoniąc super.toString():

private final class Baz extends Bar { 
    @Override 
    public String toString() { 
     return super.toString(); 
    } 
} 

Teraz wszystko trzeba robić w mock jest delegowanie przez Baz nie Bar.

W ten sposób uzyskano konkretne, ale przejrzyste wdrożenie toString(), które można kpić bez dotykania klasy Bar, która jest potencjalnie poza kontrolą.