Come posso applicare TDD alle funzioni di lettura / scrittura?

Sembra un problema di pollo e uova.

Puoi fare scrivere una funzione di scrittura in alcuni archivi di dati, ma non sai mai di averla salvata correttamente senza una funzione di lettura testata.

Puoi fare in modo che una funzione di lettura venga letta da un archivio dati, ma come metti cose in quell'archivio dati da leggere senza una funzione di scrittura testata?

MODIFICARE:

Mi sto collegando e facendo transazioni con un database SQL per salvare e caricare oggetti da usare. Non ha senso testare le funzioni di accesso fornite dal DB, ma avvolgo tali funzioni DB per serializzare / deserializzare gli oggetti. Voglio essere sicuro di scrivere e leggere correttamente le cose giuste da e verso il DB.

Non è come aggiungere / eliminare, come menziona @snowman. Voglio sapere che i contenuti che ho scritto sono corretti, ma che richiede una funzione di lettura ben testata. Quando leggo, voglio essere sicuro che la mia lettura abbia creato correttamente un oggetto uguale a quello che è stato scritto; ma ciò richiede una funzione di scrittura ben collaudata.

Inizia con la funzione di lettura.

• Nell'impostazione del test : creare il database e aggiungere i dati del test. tramite script di migrazione o da un backup. Poiché questo non è il tuo codice, non richiede un test in TDD

• Nel test : installa il tuo repository, punta al tuo db di test e chiama il metodo Read. Verificare che i dati del test vengano restituiti.

Ora hai una funzione di lettura completamente testata, puoi passare alla funzione di scrittura, che può utilizzare la lettura esistente per verificare i propri risultati

Spesso faccio solo una scrittura seguita da una lettura. ad es. (pseudocodice)

Foo foo1 = setup some object to write
File tempfile = create a tempfile, possibly in memory 
writeFoo(foo1, tempfile) 
Foo foo2 = readFoo(tempfile) 
assertEquals(foo1, foo2); 
clean-up goes here

Aggiunto in seguito

Oltre a considerare questa soluzione "prgamatica" e "abbastanza buona", si potrebbe sostenere che le altre soluzioni testano la cosa sbagliata . Testare se le stringhe o le istruzioni SQL corrispondono non è un'idea terribile, l'ho fatto da solo, ma sta testando un effetto collaterale ed è fragile. Cosa succede se si modifica la capitalizzazione, si aggiunge un campo o si aggiorna un numero di versione all'interno dei propri dati? Cosa succede se il driver SQL cambia l'ordine delle chiamate per maggiore efficienza o il serializzatore XML aggiornato aggiunge uno spazio aggiuntivo o modifica una versione dello schema?

Ora, se devi aderire in modo molto rigoroso ad alcune specifiche ufficiali, allora sono d'accordo che il controllo dei dettagli è appropriato.

Non farlo. Non eseguire I / O di unit test. È una perdita di tempo.

Logica di unit test. Se è presente molta logica che si desidera testare nel codice I / O, è necessario refactoring del codice per separare la logica di come si esegue l'I / O e ciò che si esegue dall'attività effettiva di I / O (che è quasi impossibile testare).

Per elaborare un po ', se si desidera testare un server HTTP, è necessario farlo attraverso due tipi di test: test di integrazione e test unitari. I test unitari non devono assolutamente interagire con l'I / O. È lento e introduce molte condizioni di errore che non hanno nulla a che fare con la correttezza del codice. I test unitari non dovrebbero essere soggetti allo stato della tua rete!

Il tuo codice dovrebbe separare:

• La logica di determinare quali informazioni inviare
• La logica di determinare quali byte inviare per inviare un determinato bit di informazioni (come codificare una risposta ecc. In byte non elaborati) e
• Il meccanismo per scrivere effettivamente quei byte in un socket.

I primi due riguardano la logica e le decisioni e necessitano di unit test. L'ultimo non implica prendere molte o nessuna decisione e può essere testato meravigliosamente usando i test di integrazione.

Questo è solo un buon design in generale, in realtà, ma uno dei motivi è che lo rende più facile da testare.

Ecco alcuni esempi:

• Se si sta scrivendo codice che ottiene dati da un database relazionale, è possibile testare l'unità su come mappare i dati restituiti dalle query relazionali al modello dell'applicazione.
• Se si sta scrivendo codice che scrive i dati in un database relazionale, è possibile testare unità di dati quali dati si desidera scrivere nel database senza effettivamente testare le query SQL specifiche utilizzate. Ad esempio, è possibile mantenere in memoria due copie dello stato dell'applicazione: una copia che rappresenta l'aspetto del database e la copia di lavoro. Quando si desidera eseguire la sincronizzazione con il database, è necessario differli e scrivere le differenze nel database. Puoi facilmente testare l'unità di quel codice diff.
• Se si sta scrivendo codice che legge qualcosa da un file di configurazione, si desidera testare il parser del formato del file di configurazione, ma con le stringhe del file di origine del test anziché le stringhe ottenute dal disco.

Non so se questa è una pratica standard o no, ma funziona bene per me.

Nelle implementazioni del mio metodo di lettura e scrittura non basate su database, utilizzo i miei metodi specifici toString()e il tipo fromString()come dettagli di implementazione.

Questi possono essere facilmente testati separatamente:

 assertEquals("<xml><car type='porsche'>....", new Car("porsche").toString());

Per i metodi di lettura e scrittura effettivi ho un test di integrazione che legge e scrive fisicamente in un test

A proposito: c'è qualcosa di sbagliato ad avere un test che prova a leggere / scrivere insieme?

I dati noti devono essere formattati in modo noto. Il modo più semplice per implementarlo è usare una stringa costante e confrontare il risultato, come descritto da @ k3b.

Non sei limitato alle costanti però. Potrebbero esserci un certo numero di proprietà dei dati scritti che è possibile estrarre utilizzando un diverso tipo di parser, come espressioni regolari o persino sonde ad hoc che cercano funzionalità dei dati.

Per quanto riguarda la lettura o la scrittura dei dati, può essere utile disporre di un file system in memoria che consenta di eseguire i test senza la possibilità di interferenze da altre parti del sistema. Se non si ha accesso a un buon file system in memoria, utilizzare un albero di directory temporaneo.

Usa iniezione di dipendenza e derisione.

Non si desidera testare il driver SQL e non si desidera verificare se il database SQL è in linea e configurato correttamente. Sarebbe parte di un test di integrazione o di sistema. Si desidera verificare se il codice invia le istruzioni SQL che dovrebbe inviare e se interpreta le risposte nel modo in cui dovrebbe.

Quindi, quando hai un metodo / classe che dovrebbe fare qualcosa con un database, non farlo ottenere da solo quella connessione al database. Modificarlo in modo che l'oggetto che rappresenta la connessione al database gli sia passato.

Nel tuo codice di produzione, passa l'oggetto database effettivo.

Nei test unitari, passa un oggetto simulato che si comporta come se un database reale non contatta effettivamente un server di database. Basta controllare se riceve le istruzioni SQL che dovrebbe ricevere e quindi risponde con risposte codificate.

In questo modo è possibile testare il livello di astrazione del database senza nemmeno aver bisogno di un database reale.

Se si utilizza un mappatore relazionale di oggetti, in genere esiste una libreria associata che può essere utilizzata per verificare che i mapping funzionino correttamente creando un aggregato, persistendolo e ricaricandolo da una nuova sessione, seguito da una verifica dello stato rispetto l'oggetto originale.

NHibernate offre test sulle specifiche di persistenza . Può essere configurato per funzionare contro un archivio in memoria per test di unità veloci.

Se segui la versione più semplice dei modelli di repository e Unit of Work e collaudi tutti i tuoi mapping, puoi contare su cose praticamente funzionanti.