TDD: Cosa succede prima del primo test unitario?

Comprendo principalmente la teoria del TDD, ma non riesco a capire come iniziare. Mi siedo per scrivere un test unitario per un progetto personale e realizzo. . . Non ho idea di cosa sto testando. Quali oggetti, quali funzionalità, ecc.

Ad esempio, supponiamo che io voglia scrivere un'app per aiutare la nostra famiglia a gestire i compiti domestici. Ecco alcune domande nella mia mente: come posso passare da questa idea al mio primo test? Quanto dovrebbe essere deciso prima di iniziare e quanto devo capire dopo aver iniziato a scrivere i test? Quando prendo decisioni come se archiviare i dati in un file di testo o in un database? Devo avere i test di accettazione dell'utente prima di iniziare? Dovrei avere l'interfaccia utente progettata? Dovrei avere una specifica? (Mi rendo conto che almeno alcune di queste domande di esempio sono probabilmente in una "zona grigia").

Oltre alla domanda del titolo su come arrivare al primo test unitario, potresti anche fornire un esempio di come potrebbe essere il primo test unitario per un progetto come il progetto campione?

Mi piace iniziare con un elenco di Funzionalità e per ciascuna Funzionalità scrivere le storie degli utenti, quindi per ogni Storia scrivere le descrizioni dei test.

Pensa un po 'al design, quindi scegli una descrizione del test e inizia a scrivere il codice: red-green-refactor.

Ripetere l'operazione fino al completamento di tutti i test.

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

Hai scoperto come TDD si occupa di Design sin 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 tale funzionalità funzionasse.

Anche gli sviluppatori che non usano TDD devono pensarci - ma possono "semplicemente tuffarsi" e iniziare a scrivere qualcosa, qualsiasi cosa. Ma "qualcosa, qualsiasi cosa" non è sempre sulla strada per consegnare il programma che pensavi di voler scrivere. Cosa è? Bene, come sarebbe il tuo programma se funzionasse? Quali test supererebbe?

Voglio scrivere un'app per aiutare la nostra famiglia a gestire i compiti domestici.

Freddo. Se quell'app funzionasse, cosa farebbe? Bene, un lavoro di routine 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 in cui devi iniziare, non necessariamente il posto migliore per iniziare, ma è un posto. È qualcosa che vuoi che il tuo codice supporti (anche se sono sicuro che puoi trovare nomi migliori). Inizia lì, guardalo fallire. Fallo passare. Puliscilo. Raccogliere, sciacquare, ripetere.

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

Inizia manualmente Scrivi qualcosa di simile a una storia utente:

• Come utente
• Quando seleziono Aggiungi al carrello, desidero che il prodotto venga aggiunto in modo trasparente in background
• In modo da poter continuare la mia esperienza di acquisto ininterrotta

Ora quali sono le caratteristiche che supportano quell'obiettivo (la parte "So that")?

• Quando un articolo viene aggiunto a un carrello
  • Il carrello per l'utente conterrà il nuovo articolo
  • Il totale degli articoli nel carrello aumenterà di uno
  • L'utente non deve essere reindirizzato
  • Un'opzione di check-out ora sarà disponibile
• Quando ci sono due articoli nel carrello e l'utente sceglie di effettuare il check-out
  • L'utente verrà reindirizzato alla pagina di pagamento
  • Entrambi gli oggetti saranno visibili

Queste sono tutte le cose che puoi e dovrebbero essere controllate manualmente.

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

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

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

Javascript ha jasmine e qUnit.

punto punto punto

Come posso passare da questa idea al mio primo test? Quanto dovrebbe essere deciso prima di iniziare e quanto devo capire dopo aver iniziato a scrivere i test?

Suddividi l'applicazione in storie di dimensioni ridotte. ("Come utente, voglio fare doppio clic su un'icona e avviare il programma." O "Come utente, voglio aprire il mio browser e andare al programma." Qualunque cosa.)

Quindi suddividere la storia in alcuni compiti. (ad esempio, creare un progetto in Eclipse, impostare un repository di codice) Quando si arriva a un'attività di codifica, scrivere il primo test.

Quando prendo decisioni come se archiviare i dati in un file di testo o in un 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, refactor. Se i test sono ben strutturati, dovresti essere in grado di apportare modifiche al back-end e rilevare effetti collaterali indesiderati che si verificano.

Sono sorpreso che nessuna delle risposte contenga una menzione della cosa reale che fai subito prima di scrivere il tuo primo test, che è quello di creare un elenco di test . Un elenco di test è informato dalle fasi di scrittura e progettazione della storia menzionate in altre risposte ed è il precursore diretto della stesura di un test che sembra stia cercando.

Per ulteriori informazioni su TDD, consiglierei Test Driven Development by Example di Kent Beck. Ha anche uno screencast TDD che segue lo sviluppo di una libreria non banale in puro stile TDD con spiegazioni di Kent in ogni fase del processo. Penso che sia un ottimo esempio di TDD in pratica, anche se (per necessità) viene fatto in un ambiente forzato.

Prima del primo test unitario pensi a cosa vuoi che succeda e poi pensi a come lo testeresti. Quindi scrivere quel test, vederlo fallire e implementare del codice per farlo passare.

Risciacqua, ripeti, ecc.

Per me, è il pensiero su come lo testeresti è importante ed è ciò che può guidare il tuo design.