Devi davvero fare BDD / TDD in un test per primo?

Stai parlando di BDD da una prospettiva di alto livello di test della tua interfaccia utente. I test sono un po 'più morbidi a questo livello rispetto a quelli più in basso nel tuo codice JavaScript / server.

Diversi libri che ho letto su TDD dicono che dovresti scrivere codice come se esistessero i sistemi sottostanti, e basta scrivere abbastanza per far passare il test. È possibile scrivere stub sul server per far passare i test comportamentali dell'interfaccia utente. Quindi inizi a questa giunzione di stub e scrivi alcuni test unitari per il tuo codice lato server e prosegui fino a un'implementazione completa.

Spesso codifico come se esistessero degli strati sottostanti per far passare un test di alto livello, sembra di andare in una tana del coniglio e di estrarre molte altre classi per soddisfare il test di alto livello e quindi scrivere test per questi livelli inferiori. Come hai già riconosciuto, ti aiuta a rimanere concentrato a partire da test di livello superiore.

Come ogni programmatore esperto sa, ci sono molti livelli di sviluppo del software. Io tendo a lavorare più in basso dell'interfaccia utente e penso ai dati o al comportamento che la mia UI ha bisogno dal server e inizio lì (forse perché in questi giorni non faccio molto lavoro sull'interfaccia utente).

Se sono davvero onesto, estrarre una classe dai livelli sottostanti significa che non sto facendo il test prima, ma ... entro pochi minuti o qualche volta avrò un test per quel codice. Ciò mi sembra ancora vantaggioso, in quanto mi aiuta a capire dove potresti aver bisogno di fornire dipendenze a una classe e rispettare il principio di responsabilità singola - se è difficile da testare, stai facendo troppo in un posto, ecc.

Sì! Altrimenti, ciò che ottieni è test guidato dallo sviluppo .

Realisticamente parlando, tuttavia, ci sono problemi che sono difficili da approcciare usando il TDD "puro". Potresti essere più produttivo scrivendo un codice di produzione scoperto in primo piano e coprendolo con test successivi (e imparando come affrontare problemi simili con TDD in futuro). Guarda questa tecnica , che il suo autore ha chiamato risciacquo-e -Rispondi TDD per mancanza di un termine migliore.

Se non scrivi prima i test, non guidi lo sviluppo attraverso i tuoi test. Ergo, non stai facendo uno sviluppo basato sui test!

Se vuoi lavorare in questo modo, provaci. Ma non è lo sviluppo basato sui test.

Ciò che descrivi è molto simile all'approccio Front-Ahead Design . Sfortunatamente, il Front-Ahead Design è la satira di Alex Papadimoulis per metodi agili.

Personalmente, credo che sia fondamentale pensare ai test durante la fase di progettazione. È davvero fantastico avere un'implementazione funzionante, ma l'unico modo in cui si può essere certi di avere un prodotto funzionante è se lo si è testato pezzo per pezzo. Il modo per coprirlo è una combinazione di test unitari e un team di QA qualificato che lavora in partnership.

Ora come si installa questa dicipline nel proprio team dipende da voi. TDD è una di queste strategie - e una che ha il suo posto, e ci sono molte altre varianti. Tuttavia, TDD non è particolarmente adatto allo sviluppo di layout dell'interfaccia utente.