TDD: Cosa succede prima del primo test unitario?

Mi piace iniziare con un elenco di funzionalità e, per ogni funzione, scrivere le storie degli utenti, quindi per ciascuna descrizione dei test di scrittura della storia.

Pensa al design per un po ', quindi scegli una descrizione del test e inizia la codifica: red-green-refactor.

Ripeti fino a quando non passano tutti i test.

Sì, i test di accettazione devono essere considerati come parte di questo, allegati alla storia appropriata.

Hai scoperto come TDD riguarda Design fin dall'inizio. Prima di scrivere il tuo primo test, devi pensare a quale sarà il tuo primo bit di funzionalità e quale sarebbe il tuo programma se funzionasse.

Gli sviluppatori che non usano TDD devono pensarci anche loro - ma possono "immergersi" e iniziare a scrivere qualcosa, qualsiasi cosa. Ma "qualcosa, qualsiasi cosa" non è sempre sul percorso verso la realizzazione del programma che pensavi di voler scrivere. Cosa è? Bene, come sarebbe il tuo programma se funzionasse? Quali test passerebbe?

I want to write an app to help our family manage chore assignments.

Cool. Se quell'app funzionasse, cosa farebbe? Beh, un Chore potrebbe probabilmente essere assegnato a una persona, giusto?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

C'è un inizio. Non è il posto che devi iniziare, non è necessariamente il miglior punto di partenza, ma è un posto. È qualcosa che vuoi che il tuo codice supporti (anche se sono sicuro che puoi trovare nomi migliori). Inizia da lì, guarda che fallisce. Fallo passare. Pulisci. Mescolare, sciacquare, ripetere.

Sì, TDD ha questo problema. Ecco perché ora raccomando lo sviluppo del comportamento.

Inizia manualmente. Scrivi qualcosa di simile a una user story:

• Come utente
• Quando seleziono Aggiungi al carrello Desidero che il prodotto venga aggiunto in modo trasparente sullo sfondo
• In questo modo posso continuare la mia esperienza di acquisto senza interruzioni

Ora quali sono le caratteristiche che supportano quell'obiettivo (la parte "Così quella")?

• Quando un articolo viene aggiunto a un carrello
  • Il carrello degli acquisti per l'utente conterrà il nuovo elemento
  • Gli articoli totali nel carrello aumenteranno di uno
  • L'utente non deve essere reindirizzato
  • Un'opzione check out ora sarà disponibile
• Quando ci sono due articoli nel carrello della spesa e l'utente sceglie di controllare
  • L'utente verrà reindirizzato alla pagina di checkout
  • Entrambi gli articoli saranno visibili

Queste sono tutte le cose che puoi e dovresti controllare manualmente.

Fai questo per un po '. Quindi, come un buon sviluppatore, inizia a cercare i modi per automatizzare le parti ridondanti. Questo varierà a seconda di quale sia la tua piattaforma, ma la maggior parte di questi ha quadri decenti disponibili.

.Net ha WatiN per automatizzare la pagina web o, se vuoi testare un'API, ti consiglio l'aggiunta di Subspec a xUnit o MSpec (puoi farlo anche con qualsiasi framework di testing, solo quelli rendono più facile nominare i tuoi test in un modo che supporta questo modo di pensare).

Ruby ha cetriolo per i test di automazione e rspec per il test API di livello inferiore

Javascript ha jasmine e qUnit.

punto punto punto

How do I go from this idea to my first test? How much should be decided before I start, and how much do I figure out after I start writing tests?

Rompi la tua applicazione in storie di piccole dimensioni. ("Come utente, voglio fare doppio clic su un'icona e avviare il programma." Oppure "Come utente, voglio aprire il mio browser e andare al programma." Qualunque cosa.)

Quindi suddividi la storia in alcuni compiti. (ad esempio, crea un progetto in Eclipse, configura un repository di codice) Quando arrivi a un'attività di codifica, scrivi il tuo primo test.

When do I make decisions like whether to store data in a text file or a database?

Se non sei sicuro, scegli quale mai sembra più semplice e fallo. (probabilmente il file di testo) Se ti rendi conto di aver fatto un errore, refactoring. Se i tuoi test sono ben strutturati, dovresti essere in grado di cambiare il back-end e catturare gli effetti collaterali indesiderati che spuntano.

Sono sorpreso che nessuna delle risposte contenga la cosa che fai prima di scrivere il tuo primo test, ovvero creare una lista di test . Una lista di test è informata dalle fasi di scrittura e progettazione di storie citate in altre risposte ed è il diretto precursore di scrivere un test che sembra cercare.

Per ulteriori informazioni su TDD, raccomanderei Sviluppo basato su test per esempio di Kent Beck. Ha anche uno screencast TDD che segue lo sviluppo di una libreria non banale in un TDD puro stile con spiegazioni di Kent in ogni fase del processo. Penso che sia un ottimo esempio di TDD in pratica, anche se è (per necessità) fatto in un ambiente artificioso.

Prima della prima unità di test, pensi a cosa vuoi che accada e poi pensa a come la verificherai. Quindi scrivi quel test, fallo vedere e implementa del codice per farlo passare.

Risciacquo, ripetizione, ecc.

Per me, è il modo in cui testeresti il bit che è importante ed è ciò che può guidare il tuo design.