Warum überspringt Mockito die Initialisierung der Membervariablen meiner abstrakten Klasse

Question

Ich versuche eine abstrakte Klasse zu testen und Mockito initialisiert meine Membervariablen nicht. Hier ist ein einfaches Beispiel, um Ihnen mein Problem zu zeigen.

Dies ist eine abstrakte Klasse, die ihr 'Feld' Mitglied initialisiert:

import java.util.ArrayList; 
import java.util.Collection; 

public abstract class Foo { 
    private final Collection field = new ArrayList(); 

    protected Foo() { 
     System.out.println("In constructor"); 
    } 

    public boolean isNull(Object o) { 
     field.add(o); 

     return o == null; 
    } 

    abstract void someAbstractMethod(); 
} 

Hier die Testklasse:

import org.junit.Assert; 
import org.junit.Test; 
import org.mockito.Mockito; 

public class FooTest { 
    @Test 
    public void testSomething() { 
     final Foo foo = Mockito.mock(Foo.class); 

     Mockito.when(foo.isNull(Mockito.anyObject())).thenCallRealMethod(); 

     Assert.assertFalse(foo.isNull("baaba")); 
    } 
} 

Wenn der Test wirft, weil die Variable ‚Feld ein NPE ausgeführt wird 'ist nicht initialisiert!

Was mache ich falsch?

Answer 1

Dies ist das erwartete Verhalten, wenn Sie etwas vortäuschen, was die erstellte Instanz vollständig simuliert, sodass es keinen Sinn macht, die Felder zu initialisieren, da das Verhalten standardmäßig ist.

Abgesehen davon können Felder von einem Konstruktor in konkreten oder abstrakten Klassen initialisiert werden, da die Mock-Instanziierung den Konstruktor umgeht, weil es einfach ein Spott ist, es ist noch irrationaler, sie zu initialisieren.

Der Versuch, die echte Methode aufzurufen, ist normalerweise falsch, wenn Mocks verwendet werden. Stattdessen sollte man das Verhalten des Mocks stubben.

Mockito.when(foo.isNull(Mockito.anyObject())).thenReturn(false); 
Assert.assertFalse(foo.isNull("baaba")); // assertion always passing 

Ich weiß nicht, Ihren konkreten Fall Anwendung, aber vielleicht wollen Sie eine partielle Mock, mit einem spy. Obwohl dies immer noch als schlechte Praxis angesehen wird, bedeutet dies normalerweise, dass Sie den Code neu strukturieren müssen, um Komposition zu verwenden.

Answer 2

Sie scheinen sich über die Klasse lustig zu machen, die Sie tatsächlich testen möchten. Das ist nicht wirklich die Idee zu spotten. Du machst Klassen vor, die außerhalb des Testumfangs liegen, und lässt das, was du testet, unblockiert.

In diesem Fall sollten Sie wahrscheinlich nur eine Foo mit einer Dummy-Implementierung von erstellen und diese direkt testen. Keine Notwendigkeit für irgendwelche Spott, soweit ich sehen kann.