Come testare "aggiungi" in DAO senza utilizzare "trova" ecc.?

Question

Nel seguente codice il problema è che non riesco a testare dao.add() senza utilizzare dao.list(). Size() e viceversa.

Questo approccio è normale o errato? Se non è corretto, come può essere migliorato?

public class ItemDaoTest { 

    // dao to test 
    @Autowired private ItemDao dao; 

    @Test 
    public void testAdd() { 
     // issue -> testing ADD but using LIST 

     int oldSize = dao.list().size(); 
     dao.add(new Item("stuff")); 
     assertTrue (oldSize < dao.list().size()); 
    } 

    @Test 
    public void testFind() { 
     // issue -> testing FIND but using ADD 

     Item item = new Item("stuff") 
     dao.add(item); 
     assertEquals(item, dao.find(item.getId())); 
    } 
} 

Answer 1

Penso che il test sia un test di integrazione valido come indicato sopra, ma vorrei aggiungere Add per aiutare nel test di Find e viceversa .. Ad un certo livello devi permetterti di mettere fiducia nel tuo livello più basso di integrazione alla dipendenza esterna. Mi rendo conto che esiste una dipendenza da altri metodi nei test, ma trovo che i metodi Add e Find sono metodi "di basso livello" che sono molto facili da verificare. Si testano essenzialmente a vicenda perché sono fondamentalmente metodi inversi.

Add può facilmente costruire precondizioni per trovare

Find può verificare che un add ha avuto successo.

non riesco a pensare ad uno scenario in cui un guasto in uno non sarebbe stato catturato da test

Answer 2

Io uso JDBC diretta (usando JdbcTemplate di primavera) per testare i metodi DAO. Voglio dire, chiamo i metodi DAO (che sono la base di Hibernate) e poi li confermano usando le chiamate SQL dirette di JDBC.

Answer 3

Il metodo testAdd ha un problema: dipende dal presupposto che ItemDao.list funzioni correttamente, eppure ItemDao è la classe che stai testando. I test unitari sono pensati per essere indipendenti, quindi un approccio migliore è usare il semplice JDBC - come ha detto @Amir - per verificare se il record è stato introdotto nel database.

Se si utilizza Spring, è possibile inoltrare su AbstractTransactionalDataSourceSpringContextTests per accedere alle funzioni di JDBCTemplate e assicurare un rollback dopo l'esecuzione del test.

Answer 4

La più piccola unità in prova per il test delle unità di classe a base è una classe.

capire perché, ritengono che si potrebbe, in teoria, testare ogni metodo della classe in isolamento da tutti gli altri metodi bypassando, spegnendo o beffardo. Alcuni strumenti potrebbero non supportarlo; questa è teoria non pratica, supponiamo che lo facciano.

Anche così, fare le cose in questo modo sarebbe una cattiva idea. La specificazione di una funzione individuale di per sé varia tra vagamente priva di significato e verbalmente incomprensibile. Solo nel modello di interazione tra diverse funzioni esiste una specifica più semplice del codice che è possibile utilizzare proficuamente per testarlo.

Se si aggiunge un articolo e il numero di articoli segnalati aumenta, le cose funzionano. Se c'è un modo in cui le cose non potrebbero funzionare, ma tutti i modelli di interazione rimangono, allora ti manca qualche test necessario.