Molte lune fa ho creato una libreria di utilità che avvolge le librerie JDBC con classi che consentivano approcci in stile funzionale. Ho usato questa libreria per i miei scopi per molti anni. Ho sempre desiderato realizzare questo in un vero progetto open source. Ho iniziato a un certo punto e poi mi sono occupato della vita. Con le nuove funzionalità linguistiche di Java 8, sono ri-energizzato nel fare questo. So che gli RDBM non sono più belli (sì, sono un dinosauro), ma questo è parte del motivo per cui voglio togliermi dal petto. Penso inoltre che potrebbe essere possibile estendere le astrazioni ad altre tecnologie non RDBM.
Una cosa su cui mi sono bloccato è il modo giusto per creare test unitari per questo. Voglio davvero farlo in un primo tentativo, ma non sempre mi viene naturale, quindi sto cercando un consiglio.
Generalmente non considero il raggiungimento di un database per essere nel regno dei test unitari. Ma in questo caso, l'unica cosa che fa questa libreria è di avvolgere le interazioni con il database. Potrei fare una specie di configurazione di derisione e questo potrebbe aggiungere qualche valore, ma la (percepita) complessità di farlo è un po 'scoraggiante. La mia sensazione è che finirò per impantanarmi, annoiato e alla fine lo abbandonerò di nuovo. L'altro approccio che ho usato nel mio precedente attacco a questo era usare Apache Derby in modalità embedded. Ciò ha permesso che le cose fossero autonome e avrei potuto facilmente alzarmi in piedi e abbattere i test. Ci sono varie stranezze tra i database quando si tratta di JDBC, ma non penso che questo sia un problema qui. Parte di questo è il tentativo di normalizzare questo tipo di cose tanto quanto si può fare.
L'approccio all'uso del database incorporato ha senso per questo tipo di progetto? L'opzione di derisione è più facile di quanto pensassi. C'è un altro approccio che dovrei prendere in considerazione?