Come posso utilizzare unit test e TDD per testare un'app che si basa principalmente sulle operazioni CRUD del database?

Al lavoro, uno dei miei progetti riguarda principalmente il trasferimento di dati trasmessi da un client esterno e la persistenza in un database. È un'app enterprise Java che utilizza JPA e la maggior parte della nostra logica ruota attorno alle operazioni CRUD.

La maggior parte dei nostri bug riguarda l'APP in un modo o nell'altro.

• Esempio 1: se si fa clic due volte sul pulsante Salva, JPA potrebbe tentare di inserire la stessa entità nel database una seconda volta, causando una violazione della chiave primaria.
• Esempio 2: recuperare un'entità dal database, modificarlo e provare ad aggiornare i suoi dati. JPA potrebbe tentare di creare una nuova istanza invece di aggiornare quella precedente.

Spesso la soluzione deve aggiungere / rimuovere / modificare un'annotazione JPA. Altre volte ha a che fare con la modifica della logica DAO.

Non riesco a capire come ottenere fiducia nel nostro codice usando unit test e TDD. Non sono sicuro se è perché i test unitari e il TDD non funzionano bene o se sto affrontando il problema in modo errato.

I test unitari sembrano sbagliati perché riesco a scoprire questi problemi solo in fase di esecuzione e ho bisogno di distribuirli su un server app per riprodurre i problemi. Di solito deve essere coinvolto il database che considero al di fuori della definizione di un unit test: si tratta di test di integrazione.

TDD sembra una scelta sbagliata perché il circuito di feedback deploy + test è così lento che mi rende molto improduttivo. Il ciclo di feedback deploy + test impiega più di 3 minuti, ed è solo se eseguo i test specificamente sul codice che sto scrivendo. Per eseguire tutti i test di integrazione sono necessari oltre 30 minuti.

C'è un codice al di fuori di questo stampo e lo collaudo sempre ogni volta che posso. Ma la maggior parte dei nostri bug e i più grandi intervalli di tempo coinvolgono sempre JPA o il database.

C'è un'altra domanda che è simile , ma se seguissi il consiglio starei avvolgendo la parte più instabile del mio codice (JPA) e testando tutto tranne che. Nel contesto della mia domanda, mi troverei nella stessa brutta situazione. Qual è il prossimo passo dopo aver concluso l'APP? IMO quella domanda è (forse) un passo per rispondere alla mia domanda, ma non una risposta ad essa.

Un'opzione è utilizzare un database di test in memoria come H2 ; tende a essere circa 10 volte più veloce di un database standard che utilizza un disco e con tempi di avvio / smontaggio inferiori.

L'aiuto dipenderà in gran parte dal fatto che i problemi di JPA che stai riscontrando siano abbastanza generali da non riuscire ancora su database diversi. Non è molto importante eseguire i test più velocemente se perdono la maggior parte dei problemi.

Ma se riesci a fare 10 corse con H2 per ognuna con il sistema completo, potrebbe pagare.

I database possono essere molto facili da testare in unità: sono necessarie procedure e transazioni memorizzate.

Questo è ciò che dice Microsoft sui test delle unità di database . Puoi anche eseguire unit test su un database, scrivere i tuoi test in Java o C # impostando una connessione DB, avviando una transazione, scrivendo tutti i dati che vuoi utilizzare per il test sul DB, eseguendo i test e quindi eseguendo il rollback. Nessun danno al DB se ne stavi usando uno che hai anche distribuito e ottieni test completamente isolati.

Spero che questo possa darti un'idea di come farlo nel tuo framework.

Altre persone hanno risposto con "Mock out your DB!" - ma che senso ha deridere il tuo livello DB se hai davvero bisogno di testare come interagisce con il tuo codice?

Quello che stai cercando sono i test di integrazione e / o i test automatici dell'interfaccia utente. Hai detto che il problema si verifica quando:

*If you click the save button twice*

L'unico modo per verificarlo è scrivere un test UI automatizzato per fare clic due volte sul pulsante. Forse dai un'occhiata al selenio.

Probabilmente avrai anche bisogno di un DB di unit test e per i tuoi test puntalo verso quello. Un dolore da mantenere ma benvenuto nel TDD nel mondo reale.

Nell'esempio fornito nella domanda, non è possibile eseguire unit test / TDD sulla situazione facendo clic due volte sul pulsante per causare un errore molto facilmente. Ma ciò che puoi testare l'unità è che nel codice che viene chiamato quando fai clic sul pulsante, se ottieni un'eccezione dal livello di persistenza, lo gestisci in modo appropriato (deridendo il livello di persistenza o utilizzando un database in memoria come è stato suggerito in altre risposte) - ricodificando o visualizzando un errore o altro.

Hai ragione sul fatto che TDD può iniziare a rompersi quando è necessario eseguire test che non si adattano bene a un test unitario (ad esempio test di integrazione / sistema) - questo ha costituito un bel po 'della discussione nel recente "Is TDD Morto?" dibattiti tra Kent Beck, Martin Fowler e David Heinemeier Hansson: http://martinfowler.com/articles/is-tdd-dead/