Riempire il divario tra concezione e test unitario

Due cose potrebbero aiutarti lì:

• Invece di casi d'uso, User Story. Perché? Bene Le User story sono scritte per / dall'utente. Non sono una descrizione accurata della funzionalità, ma specificano ciò che l'utente vuole fare. Questa può essere la tua road map iniziale nel codice di scrittura che consente effettivamente all'utente di fare qualcosa, piuttosto che rispettare le specifiche del sistema.

• Un diagramma di classe. Una volta compresa la funzionalità che desideri codificare, devi creare il modello che utilizzerai. Questo non deve essere completo o esteso; l'idea è che definirai il tuo design (e di quali classi hai bisogno) mentre fai i test (questo è il motivo per cui TDD è 'design'), ma devi sapere di quali classi hai bisogno, le proprietà che hanno, ecc.

Se lavori con storie di piccoli utenti (come di solito sono), il tuo diagramma di classe sarà piccolo. Quindi è davvero più che hai bisogno dell'idea di quali classi avrai bisogno.

Non puoi saltare direttamente da "idea" a "implementazione". Un buon esempio è il "modello V":

Inizi ad alto livello, vai più in basso e scrivi test su ogni livello. E ogni livello diventa più specifico sia nell'implementazione che nel test. Ad esempio, scrivi un test di accettazione che dice che dovresti essere in grado di aggiungere un cliente. Ciò comporta la scrittura di test di integrazione per garantire che il client possa essere creato e inserito nel database. E questo ti costringe a scrivere test unitari che descrivono condizioni dettagliate per la creazione e il salvataggio dell'oggetto cliente. E quindi si implementa il codice fino al passaggio del test unitario, questo farà passare i test di integrazione e passerà i test di accettazione. Quindi ottieni pochi test di accettazione di alto livello, più test di integrazione e un sacco di test unitari piccoli e dettagliati.

Scrivere casi d'uso con (diciamo il proprietario di un prodotto) potrebbe forse aiutarti a iniziare. Il problema per me è che la "concezione" nel tuo grafico e nei test di unità sono su diversi livelli concettuali. I test unitari sono a un livello molto basso (e sono meglio visti come uno strumento di progettazione del codice), non dettano o garantiscono le funzionalità a livello di sistema.

Vorrei iniziare scrivendo test di accettazione ad alto livello automatizzati (e potresti farlo in NUnit se vuoi).

EDIT: Penso che sia difficile dire esattamente cosa dovresti sostituire ??? nel diagramma. Se il concetto è definito e ben noto allo sviluppatore, sarà in grado di iniziare a scrivere direttamente il test unitario. Se il concetto non è ben definito allora direi "collaborazione" (come in: tu come sviluppatore devi parlare con qualcuno vai a ottenere più informazioni in modo che tu possa scrivere i test e il codice). Forse questo potrebbe essere formalizzato in "creare casi d'uso" - poiché è necessario raccogliere informazioni per poterlo realizzare.

Per me quel tipo di processo dovrebbe essere separato dal processo TDD quindi forse è meglio rimuovere il ??? box - e tratta semplicemente il problema "Non so come funzioni questa funzione, quindi non posso costruirla?" come un processo diverso.

Un test ti dice fondamentalmente: "Se fornisco l'input X al programma P, ottengo l'output Y." Lo sviluppo del test guidato funziona scrivendo prima X e Y, quindi riempiendo il gap.

Lavora all'indietro. Il programma produrrà alcune uscite. Che si tratti di segnali di controllo, immagini, pagine web, testo, lampade, toast, qualsiasi cosa: uscite. Produci alcune uscite rappresentative a mano.

Ci sarà bisogno di una sorta di modello di dati per il sistema. Questo può essere banale come un singolo numero o un insieme complesso di oggetti di business o un modello numerico completo dell'atmosfera. È qui che le persone distribuiscono UML, BCNF e così via. Non puoi evitare di ragionare sul modello dati, ma puoi metterlo in relazione con i tuoi esempi di output. "L'uscita X1 è visibile quando il modello dati contiene D1". Così finisci per scrivere un set di formattatori di output e postprocessori dai loro test.

link : TDD è un metodologia e mezzi per organizzare il lavoro di produzione del programma. Devi prima qualcosa e in TDD scrivere un test. Non ti assolve dal dover fare architettura.