Usa Mockito per deridere alcuni metodi ma non altri

Esiste un modo, usando Mockito, per deridere alcuni metodi in una classe, ma non altri?

Ad esempio, in questa Stockclasse (dichiaratamente inventata) voglio deridere i valori getPrice()e getQuantity()restituire (come mostrato nello snippet di prova di seguito) ma voglio getValue()eseguire la moltiplicazione come codificato nella Stockclasse

public class Stock {
  private final double price;
  private final int quantity;

  Stock(double price, int quantity) {
    this.price = price;
    this.quantity = quantity;
  }

  public double getPrice() {
    return price;
  }

  public int getQuantity() {
    return quantity;
  }
  public double getValue() {
    return getPrice() * getQuantity();
  }

  @Test
  public void getValueTest() {
    Stock stock = mock(Stock.class);
    when(stock.getPrice()).thenReturn(100.00);
    when(stock.getQuantity()).thenReturn(200);
    double value = stock.getValue();
    // Unfortunately the following assert fails, because the mock Stock getValue() method does not perform the Stock.getValue() calculation code.
    assertEquals("Stock value not correct", 100.00*200, value, .00001);
}

Per rispondere direttamente alla tua domanda, sì, puoi deridere alcuni metodi senza deridere altri. Questo si chiama derisione parziale . Vedere la documentazione di Mockito su simulazioni parziali per ulteriori informazioni.

Per il tuo esempio, puoi fare qualcosa come il seguente, nel tuo test:

Stock stock = mock(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
when(stock.getValue()).thenCallRealMethod();  // Real implementation

In tal caso, ogni implementazione del metodo viene derisa, a meno che non sia specificato thenCallRealMethod()nella when(..)clausola.

C'è anche una possibilità viceversa con spia invece di derisione :

Stock stock = spy(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
// All other method call will use the real implementations

In tal caso, tutte le implementazioni del metodo sono quelle reali, tranne se hai definito un comportamento beffardo con when(..).

C'è una trappola importante quando si usa la when(Object)spia come nell'esempio precedente. Verrà chiamato il metodo reale (perché stock.getPrice()viene valutato prima when(..)in fase di esecuzione). Questo può essere un problema se il tuo metodo contiene una logica che non dovrebbe essere chiamata. Puoi scrivere l'esempio precedente in questo modo:

Stock stock = spy(Stock.class);
doReturn(100.00).when(stock).getPrice();    // Mock implementation
doReturn(200).when(stock).getQuantity();    // Mock implementation
// All other method call will use the real implementations

Un'altra possibilità potrebbe essere quella di utilizzare org.mockito.Mockito.CALLS_REAL_METHODS, come ad esempio:

Stock MOCK_STOCK = Mockito.mock( Stock.class, CALLS_REAL_METHODS );

Ciò delega le chiamate non controllate a implementazioni reali.

Tuttavia, con il tuo esempio, credo che fallirà ancora, poiché l'implementazione di getValue()fa affidamento quantitye price, piuttosto che getQuantity()e getPrice(), che è ciò che hai deriso.

Un'altra possibilità è quella di evitare del tutto le derisioni:

@Test
public void getValueTest() {
    Stock stock = new Stock(100.00, 200);
    double value = stock.getValue();
    assertEquals("Stock value not correct", 100.00*200, value, .00001);
}

Il derisione parziale di una classe è supportato anche tramite Spy in mockito

List list = new LinkedList();
List spy = spy(list);

//optionally, you can stub out some methods:
when(spy.size()).thenReturn(100);

//using the spy calls real methods
spy.add("one");
spy.add("two");

//size() method was stubbed - 100 is printed
System.out.println(spy.size());

Controlla i documenti 1.10.19e 2.7.22per una spiegazione dettagliata.

Secondo i documenti :

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

// this calls the real implementation of Foo.getSomething()
value = mock.getSomething();

when(mock.getSomething()).thenReturn(fakeValue);

// now fakeValue is returned
value = mock.getSomething();

Quello che vuoi è org.mockito.Mockito.CALLS_REAL_METHODSsecondo i documenti:

/**
 * Optional <code>Answer</code> to be used with {@link Mockito#mock(Class, Answer)}
 * <p>
 * {@link Answer} can be used to define the return values of unstubbed invocations.
 * <p>
 * This implementation can be helpful when working with legacy code.
 * When this implementation is used, unstubbed methods will delegate to the real implementation.
 * This is a way to create a partial mock object that calls real methods by default.
 * <p>
 * As usual you are going to read <b>the partial mock warning</b>:
 * Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
 * How does partial mock fit into this paradigm? Well, it just doesn't... 
 * Partial mock usually means that the complexity has been moved to a different method on the same object.
 * In most cases, this is not the way you want to design your application.
 * <p>
 * However, there are rare cases when partial mocks come handy: 
 * dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
 * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
 * <p>
 * Example:
 * <pre class="code"><code class="java">
 * Foo mock = mock(Foo.class, CALLS_REAL_METHODS);
 *
 * // this calls the real implementation of Foo.getSomething()
 * value = mock.getSomething();
 *
 * when(mock.getSomething()).thenReturn(fakeValue);
 *
 * // now fakeValue is returned
 * value = mock.getSomething();
 * </code></pre>
 */

Quindi il tuo codice dovrebbe apparire come:

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

public class StockTest {

    public class Stock {
        private final double price;
        private final int quantity;

        Stock(double price, int quantity) {
            this.price = price;
            this.quantity = quantity;
        }

        public double getPrice() {
            return price;
        }

        public int getQuantity() {
            return quantity;
        }

        public double getValue() {
            return getPrice() * getQuantity();
        }
    }

    @Test
    public void getValueTest() {
        Stock stock = mock(Stock.class, withSettings().defaultAnswer(CALLS_REAL_METHODS));
        when(stock.getPrice()).thenReturn(100.00);
        when(stock.getQuantity()).thenReturn(200);
        double value = stock.getValue();

        assertEquals("Stock value not correct", 100.00 * 200, value, .00001);
    }
}

La chiamata alle Stock stock = mock(Stock.class);chiamate org.mockito.Mockito.mock(Class<T>)che assomiglia a questa:

 public static <T> T mock(Class<T> classToMock) {
    return mock(classToMock, withSettings().defaultAnswer(RETURNS_DEFAULTS));
}

I documenti del valore RETURNS_DEFAULTSdicono:

/**
 * The default <code>Answer</code> of every mock <b>if</b> the mock was not stubbed.
 * Typically it just returns some empty value. 
 * <p>
 * {@link Answer} can be used to define the return values of unstubbed invocations. 
 * <p>
 * This implementation first tries the global configuration. 
 * If there is no global configuration then it uses {@link ReturnsEmptyValues} (returns zeros, empty collections, nulls, etc.)
 */

Deridere parzialmente usando il metodo spia di Mockito potrebbe essere la soluzione al tuo problema, come già affermato nelle risposte sopra. In una certa misura concordo sul fatto che, per il tuo caso d'uso concreto, potrebbe essere più appropriato deridere la ricerca del DB. Dalla mia esperienza questo non è sempre possibile - almeno non senza altre soluzioni alternative - che considererei molto ingombrante o almeno fragile. Nota che il derisione parziale non funziona con le versioni alleate di Mockito. Hai usato almeno 1.8.0.

Avrei appena scritto un semplice commento per la domanda originale invece di pubblicare questa risposta, ma StackOverflow non lo consente.

Solo un'altra cosa: non riesco davvero a capire che molte volte una domanda viene posta qui ottiene un commento con "Perché vuoi farlo" senza almeno cercare di capire il problema. Soprattutto quando si tratta quindi di deridere parzialmente ci sono davvero molti casi d'uso che potrei immaginare dove sarebbe utile. Ecco perché i ragazzi di Mockito hanno fornito questa funzionalità. Naturalmente questa funzione non dovrebbe essere abusata. Ma quando parliamo di configurazioni di casi di test che altrimenti non potrebbero essere stabilite in modo molto complicato, si dovrebbe usare lo spionaggio.