Come si deve testare l'unità Java che chiama una procedura memorizzata MySQL?

Question

Sto scrivendo una semplice applicazione che leggerà alcuni record e li inserirà in un database. Ho scritto una stored procedure che gestisce la logica di inserimento e ho pianificato di testarla separatamente. Ora mi piacerebbe scrivere un buon test unitario per la parte della logica che prende un oggetto business e lo passa alla chiamata della procedura memorizzata.

ho penso quello che voglio fare è passare un mock della connessione al database, quindi affermare che la chiamata viene effettuata con i valori dei parametri previsti:

Connection dbConnection = makeMockConnection(); // how? 
MyObjectWriter writer = new MyObjectWriter(dbConnection); 
writer.write(someSampleObject); 
// somehow assert that dbConnection called 
// `sp_saveMyObject` with param values x, y, and z 

Tuttavia, sembra come un sacco di lavoro scavare all'interno di java.sql.Connection, capire come funziona, quindi prendere in giro tutti i risultati. C'è una libreria di test che fa tutto questo per me? Sto arrivando a questo nel modo sbagliato?

Answer 1

È possibile creare un database HSSQL in memoria con una procedura memorizzata fittizia. Il motto sproc avrebbe inserito una riga in una tabella per mostrare che era in esecuzione e quali erano i suoi parametri. Esegui il codice sotto test e poi guarda nel db per vedere cosa è successo.

Answer 2

È possibile utilizzare il modello di progettazione Decorator per il collegamento mocking. Si crea una connessione reale al DB con il driver che si utilizza, che è racchiuso dalla classe ConnectionImpl che implementa l'interfaccia di connessione e mantiene la connessione reale come membro.
Ogni chiamata reale che non si vuole effettivamente fare, sostituirla con un codice simulato, e ogni chiamata i soggiorni chiama lo stesso metodo dell'oggetto di connessione reale (Delegare la chiamata).
In questo modo si sta codificando come al solito, differiscono solo nell'oggetto restituito dal metodo che crea la connessione.
Ora, nell'oggetto mock (il tuo ConnectionImpl) è possibile aggiungere un codice di test dell'unità che controlla l'input, ad esempio.

Answer 3

Se non si è interessati a come funziona MyObjectWriter, basta che lo faccia, quindi sarei propenso a scrivere un test di integrazione e dimenticare un test unitario.

Tu non parlare di come si sta testando la stored procedure, così mi perdoni, ma quello che vorrei fare è scrivere i test in tutto MyObjectWriter che invocano la-stored procedure in un database e quindi verificare lo stato del database in seguito. Userei un database in memoria, se possibile, per mantenere basse le durate del test.