Unità che verifica gli oggetti di accesso ai dati

Question

Unità che verifica gli oggetti di accesso ai dati

#1 da (7 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (1 voti)

5

Recentemente ho iniziato a utilizzare lo sviluppo basato su test e il collaudo di unità, e ha pagato immensamente nelle aree in cui l'ho applicato. Un'area in cui è stato utile è l'accesso al database. Quando estrai l'accesso ai dati, la verifica dei metodi che richiedono i dati diventa quasi ridicolmente facile.

Tuttavia, non sono stato in grado di trovare o capire un modo per testare i DAO stessi. (Sarebbe controproducente estrapolarli!) Un DAO in teoria dovrebbe semplicemente spostare i dati avanti e indietro tra il database e l'applicazione; può essere considerato troppo semplice da testare?

Ho sperimentato l'installazione di un database Derby sul mio computer locale per i test, ma è difficile automatizzare l'avvio del server, la creazione dei database e la creazione delle tabelle.

Esiste un modo per automatizzare il test degli oggetti di accesso ai dati?

tdd unit-testing database-development

posta Michael K 14.02.2011 - 18:04

fonte

4 risposte

Leggi altre domande sui tag tdd unit-testing database-development

Direzione strategica e tattica per i team IT Come sono progettati i linguaggi di programmazione? [chiuso]

score 7 · Answer 1

Se vuoi automatizzare questo tipo di test (sono d'accordo con Gary che è l'integrazione piuttosto che il test unitario), dai un'occhiata a DBunit . È un framework che consente di impostare una copia del database pulita per ogni test, consentendo di eseguire test su dati noti in modo automatico. Combinalo con il database Hypersonic in memoria per la velocità.

score 2 · Answer 2

Determina ciò che devi testare e poi testarlo

Nel caso di un DAO tipico, prende alcuni parametri, li applica per formare una query, ottiene i risultati, forse li armeggia con un po 'e poi li restituisce.

Ovviamente, all'interno di questa lista ci sono molte opportunità per introdurre framework helper (in Java questo sarebbe template Spring, oggetti Hibernate Query e così via). Quindi, guarda il tuo DAO, determina come interagisce con altri oggetti di supporto e prendi in giro quegli oggetti di supporto.

Ricorda che il tuo test è interessato a verificare che il flusso di dati DAO sia corretto , non stai provando a verificare che il framework di supporto funzioni (questo è il lavoro dei loro test unitari).

Se ti trovi sulla strada della creazione di database, sei fuori dai test unitari e dai test di integrazione o di funzionalità. Questi sono appropriati quando è necessario testare la qualità delle query con i set di dati di produzione rappresentativi.

score 2 · Answer 3

L'intero punto di un test unitario è di testare una singola unità di comportamento in completo isolamento. L'intero punto di un DAO è di integrarsi con alcuni servizi esterni (database, file system, servizi Web, ...)

Semplicemente non puoi testarlo. Invece, rendi tutto così semplice, piccolo, diretto e "stupido" che sia "ovviamente corretto". Oh, quello, e l'integrazione testate il youknow che cosa c'è , perché nothing è mai corretto, non importa quanto sia ovvio.

can this be considered too simple to test

Non è che troppo semplice per testare, è che il punto chiave di un DAO è lavorare insieme ad altri materiali (termine tecnico :-)), mentre lo scopo di un test unitario è per testare le cose in isolamento. Esistono molti altri tipi di test (test di integrazione, test funzionali) che possono essere utilizzati per testare i DAO, ma non i test unitari.

score 1 · Answer 4

Uno dei mantra di XP è "Prova tutto ciò che può eventualmente rompersi". Alcune persone credono che questo significhi che ogni linea di codice dovrebbe essere testata.

Tuttavia, ho un approccio più pragmatico. Se non credo che vi sia il rischio che alcune parti del sistema vengano interrotte se un altro sviluppatore ha apportato modifiche, non trovo necessario includere un test per questo, ad es. controllo degli argomenti di input per valori nulli.

Quindi, nella tua domanda, se ritieni che il codice sia così semplice, che una volta scritto, non si romperà quando qualcuno toccherà il codice, quindi no, non mi preoccuperei di scrivere test per questo.

Detto questo, spesso scrivo i test per cominciare, perché è così che verificherei che questo modulo funzioni quando lo scrivo per cominciare. Se non si dispone del test, è necessario eseguire l'intera applicazione per verificare che il codice di accesso ai dati funzioni.