È una cattiva pratica codificare la soluzione, quindi ripetere in TDD?

Non sei il primo a inciampare sul fatto che TDD non riesca a trovare una fase di ricerca della soluzione. Ecco un link a un blog tedesco che riassume un intero serie di articoli di Ralf Westphal sull'argomento. Se non parli tedesco, prova Google translate. Almeno puoi guardare la grafica nel mezzo , scetching come potrebbe essere "TDD 2.0".

(Gli articoli di Westphal non sono disponibili sul Web, AFAIK, ma puoi trovare alcune delle sue idee nel suo blog ).

By coding the solution

Questo è IMHO non l'approccio migliore. "La ricerca di soluzioni" è idealmente una fase senza codifica (completa) . Puoi scansionare l'API nel codice, puoi scrivere alcuni commenti concettuali in linguaggio naturale o qualche pseudo codice di alto livello, ma non lasciare che i dettagli di implementazione disturbino il tuo processo di pensiero. È un approccio dall'alto verso il basso, in contrasto con il solito processo "dal basso verso l'alto" di TDD.

Se inizi a "programmare prima una soluzione", probabilmente non farai alcun TDD: rischi di non scrivere abbastanza test per assicurarti che ogni aspetto importante della tua soluzione sia coperto, prendi un alto rischio di implementare le cose "nel caso in cui", anche se non ne hai ancora bisogno (ancora), e non pensi davvero ai requisiti dell'API dal punto di vista di un utente della tua API.

Questa è una saggezza molto antica: quando ero a scuola (> 30 anni fa), ho già imparato i termini "dal basso verso l'alto" e "dall'alto in basso" come tecniche di programmazione che si supportano a vicenda. "TDD by the book" copre solo l'aspetto "dal basso verso l'alto", l'aspetto "top-down" viene introdotto facendo esplicitamente (almeno un po ') l'analisi e la progettazione.

Quindi sì, lo sviluppo di una soluzione prima va bene, ma se si desidera TDD, non implementare le soluzioni in codice prima di iniziare a scrivere test.

Sì, è una cattiva pratica.

Non a causa della tua fase di soluzione, ma a causa del tuo commento e artificioso TDD virato alla fine.

Se hai la soluzione codificata, aggiungi semplicemente i test e hai finito.

Non provare a spremere in una pratica solo perché vuoi dire 'abbiamo fatto TDD'.

Fai ciò che funziona e poi dì "non abbiamo fatto TDD perché le soluzioni non appaiono magicamente dai passaggi iterativi"

Scegli un nome per la tua nuova metodologia * e scrivi un libro a riguardo. Passaggio 3: profitto!

* non STDD

1. Code the solution
2. Comment the solution and follow the standard formula (Green, Red, Refactor)

In realtà non sei così lontano da un modello comune in TDD. Il tuo passaggio n. 1 è analogo a una soluzione per spike . James Shore introduce spighe in questo modo

We perform small, isolated experiments when we need more information.

In TDD, lo spike viene scartato e una nuova implementazione è progettata da zero.

Conversely, writing a test seems to be only a speculation that a problem will be solved once it passes.

Assolutamente no - spesso passiamo un test semplicemente inserendo la risposta giusta nel codice di produzione. Nessuno ritiene che il problema sia "risolto" a questo punto, solo che il test è calibrato e rileverà un particolare errore.

In realtà la risoluzione del problema si verifica di solito sotto la barra verde.

Per capire la differenza tra ciò che stai facendo e TDD, può aiutare a rivedere la differenza tra test e controllo . Nel processo che descrivi, stai aggiungendo assegni calibrati al codice che hai scritto, ma non stai veramente testando il design .

Il TDD va deliberatamente in senso inverso - progettiamo scrivendo i test e prestando attenzione a come l'API si sente di usare. Quindi creiamo una soluzione vincolata dal nostro design API.

La scrittura di assegni conformi a una soluzione pre-inscatolata è una delle tecniche che usiamo per gestire il codice legacy ; stiamo operando con un diverso insieme di limitazioni, quindi utilizziamo tecniche diverse.

Ma aggiungere volontariamente un vincolo legacy quando si crea qualcosa di nuovo sembra tornare in primo piano.

Sia i test che il codice di implementazione dovrebbero derivare dai requisiti. Una delle idee principali alla base di TDD è che ti costringe a pensare alle interfacce (e mantenerle semplici) in primo piano, dal momento che devi fornire input e acquisire output allo stesso modo di qualsiasi altro utente del tuo codice. Tuttavia, dovresti sempre essere in grado di scriverne uno senza l'altro se sei premuroso e le tue esigenze sono ben definite.

Se non sai quale software stai scrivendo, devi prima stabilirlo come requisiti. Se lo fai, dovresti fare attenzione a evitare di accoppiare strettamente i tuoi test all'implementazione; rende il sistema fragile e difficile da aggiornare. Quello che stai suggerendo suona molto come se si tradurrebbe in questo, o almeno essere esattamente come seguire un test-ultima metodologia, mentre semplicemente rendere le cose più difficili per te stesso nel mezzo.

Tuttavia, ci sono certamente casi in cui i test basati sui requisiti si interrompono. I requisiti a volte cambiano, e spesso non c'è proprio nulla che tu possa fare al riguardo, oltre ad adattarti. (E hanno dei difetti, e tu itera.) Ma quando cambia l'implementazione specifica, l'interfaccia non dovrebbe; nel senso, i tuoi test per queste interfacce rimangono validi. Puoi e dovresti aggiungere test man mano che procedi per coprire casi specifici per la tua implementazione, e così via, quando segui TDD.

L'idea di TDD non è solo un test, ma guida anche lo sviluppo, in modo che l'analisi delle unità sia testabile. Preferisco chiamare la tua "Solutuion" a "Prototype", che può aiutare a cancellare l'attività, ma generalmente non dovrebbe essere ereditata dalla produzione.

Conversely, writing a test seems to be only a speculation that a problem will be solved once it passes. By coding first, you are assured that you will do the good verifications.

Per quanto ho capito, la soluzione potrebbe essere "testare di più". O, piuttosto, progetta la tua atrchitecture e verifica in modo che tutti i casi siano coperti. Un prototipo potrebbe aiutare anche con quello.

Se prima codifichi la tua soluzione e poi scrivi i test per questo, è BDD. Quindi credo che quello che stai cercando di fare non sia una cattiva pratica, non è solo TDD.