TDD: Dove dovrei iniziare?

Sembra che tu stia mescolando BDD (sviluppo guidato dal comportamento) con TDD (che non è sorprendente dato che sono discutibilmente molto simili).

BDD è un processo più grande rispetto ai soli test, ma per concentrarsi su ciò che è rilevante per la tua domanda:

1. individua un'importante funzione che desideri implementare.
2. scegli uno scenario specifico che ritieni sia un esempio rappresentativo della funzione (personalmente preferirei il percorso più semplice e felice anziché immergerti in eccezioni o casi limite).
3. scrivi un test al livello di astrazione più vicino allo scenario / alle specifiche. fai strada all'esterno attraverso ogni livello di astrazione fino a quando lo scenario non è completamente implementato.
4. se non hai coperto la funzione vai su 2 e ripeti finché non hai implementato tutti gli scenari rilevanti per la funzione
5. altrimenti vai a 1 e ripeti fino a fine

Penso che questo approccio sia più adatto quando si implementa qualcosa di molto "business", nelle rare occasioni in cui devo fare qualcosa di moderatamente complesso a un livello basso (ad es. qualcosa con una inclinazione più algoritmica o tecnica) quindi diventa meno utile fare picchi verticali ed è più facile rimanere nello stesso livello di astrazione e lavorare con un approccio più formale ai casi limite, alle condizioni pre e post, ecc.

Modifica: oh, e sì se stai facendo fuori nel controllare che il modulo (o più correttamente abbastanza del modulo per implementare il tuo scenario) appaia correttamente è un buon inizio - non mettere troppa enfasi sul test del Tuttavia, la GUI si può facilmente impantanare in fragili test.

Spesso trovo più facile iniziare con i test per la gestione degli errori. Nel tuo caso questo potrebbe essere: if there is no client in database with given ID, raise an Exception .

I've learned that I should not write tests for methods or class. I should write tests for behaviors.

Questo non è vero. I tuoi metodi dovrebbero esprimere i tuoi comportamenti e tu dovresti testare l'unità / l'integrazione con quei metodi e classi.

Hai detto di usare PHP, beh, i siti PHP di solito non hanno una logica aziendale complessa. (disclaimer: ho detto di solito ) La parte più complessa è l'interfaccia utente, quindi quello che puoi fare è passare prima a fare MVC, e poi vedrai dove si adattano i tuoi test. Quando hai metodi espliciti sul tuo controller, puoi facilmente estrarre alcuni comportamenti in un test che ha un certo valore.

save my customers information to consult that later.

Quindi penso che un buon test sarebbe vedere se hai un file sul tuo hard disk, o una voce in un database, che contiene tutte le "informazioni sui clienti". Oppure simuli un utente che arriva sul tuo sito, fa qualsiasi cosa e vede se le informazioni sono state salvate correttamente.

Quali informazioni? Sì ... questa è una buona domanda.

Il tuo esempio è poco ampio. Scegli una piccola parte del problema con cui iniziare.

Ci sono un numero qualsiasi di posti da cui iniziare. Puoi iniziare con il caricamento della pagina per il modulo. (Il selenio è uno strumento piacevole che si integra con PHPUnit link ) o l'elaborazione delle informazioni sul back-end. Avrai una sorta di funzione / metodo che elaborerà i dati. Che cosa farà questo metodo? Scrivi le informazioni in un database? Restituirlo formattato in un modo specifico? E i dati non validi?

Dovresti avere una storia o un processo in mente. Ad esempio, John Smith compila un modulo con il suo nome e indirizzo. Quindi puoi iniziare con un test assicurando che a una pagina venga fornito un campo nome e indirizzo. Passare al passaggio successivo, John Smith invia il modulo e i dati memorizzati in un database. Quindi scrivi un test che assicura che i dati inviati vengano inseriti nel tuo database. Ripeti.

TDD aiuta a servire a due scopi, il primo è la conferma che il codice che sto scrivendo si comporta come voglio e può essere modificato senza causare nuovi bug. E in secondo luogo come guida per ciò che il codice deve fare. Se mi fornisci i tuoi test, dovrei essere in grado di trovare una soluzione simile al problema (l'unica differenza sono i nostri singoli stili di codifica).