Credo che l'esistenza di questo test unitario sia giustificata. Tuttavia, per me, questo test unitario sembra molto accoppiato all'implementazione del metodo, anche se non sono sicuro che possa essere migliorato.
class ItemManager {
void save(Item item) {
if (item.id == null)
create(item)
else
update(item)
}
}
@Test
public void save() throws Exception {
ItemManager manager = spy(new ItemManager());
doNothing().when(manager).create(any(Item.class));
doNothing().when(manager).update(any(Item.class));
Item item = new Item();
manager.save(item);
verify(manager, (times(1))).create(item);
item.setId("id");
manager.save(item);
verify(manager, (times(1))).update(item);
}
Modifica:
Sembra che ci siano due problemi con questo test unitario, l'accoppiamento con l'implementazione e che il test copra due comportamenti. Sono d'accordo che i due comportamenti dovrebbero essere divisi in test separati e capire che l'accoppiamento è indesiderabile, ma non sono ancora sicuro di quale sarebbe il modo appropriato per testarlo.
Sembra che il modo corretto di testare il comportamento di save sia di verificare che si traduca nelle chiamate previste del mio livello di persistenza. Tuttavia, questo sembra molto ridondante con i test unitari dei metodi create e update .
La ridondanza nel test sottostante è appropriata? Qualche suggerimento per migliorare?
Dao mockDao;
@Test
public void create() {
manager.create(new Item());
verify(mockDao).insert("expected params");
}
@Test
public void update() {
Item item = new Item();
item.setId("id");
manager.update(item);
verify(mockDao).update("expected params");
}
@Test
public void saveWithoutId() {
manager.save(new Item());
verify(mockDao).insert("expected params");
}
@Test
public void saveWithId() {
Item item = new Item();
item.setId("id");
manager.save(item);
verify(mockDao).update("expected params");
}