Qual è il flusso di lavoro più elementare per TDD?

Il flusso di lavoro di base per TDD è comunemente noto come "Red; Green; Refactor":

1. Rosso: scrivi un test fallito
2. Verde: modifica il codice per effettuare il test pass (senza che nessun test esistente abbia esito negativo)
3. Refactor: riordina il codice per incorporare meglio la modifica.

Ci sono numerose risorse che spiegano questo processo in dettaglio, ad esempio I cicli di TDD

Non mi è chiaro quale sia la rilevanza dei tuoi commenti su src/main e src/test e rami su questo processo. Tuttavia, per quanto riguarda le build: è necessario eseguire una compilazione completa e rieseguire tutti i test dopo ciascuno dei tre passaggi precedenti. I test rimangono parte della tua fonte, sempre, poiché l'idea è di rieseguire tutti i test dopo tutte le modifiche per assicurarti di non aver rotto un test non correlato (e quindi una funzionalità) con una modifica.

Normalmente manterrai i tuoi test in una gerarchia di cartelle separate poiché di solito non fanno parte del binario che spedisci, ed è più semplice non mischiarli, ma li tieni nello stesso repository e succursale perché appartengono insieme nella fonte.

Per quanto riguarda il luogo in cui lavori, TDD significa Test Driven Development, che significa che devi prima scrivere un test (piccolo) per la funzione che vuoi che il tuo codice fornisca. Lo fai funzionare e lo guardi fallire; rosso. Quindi si implementa funzionalmente nel "modo più semplice possibile" fino a quando il test ha esito positivo; verde. Puoi quindi opzionalmente rifattare il codice mantenendo il test verde. Poi torni a scrivere un altro test fallito, e così via.

Aggiungendo test per le funzionalità aggiuntive in questo modo e implementando le funzionalità in piccoli incrementi, riduci alcune delle tue congetture che normalmente si verificano quando provi a scrivere il codice prima dei test. I test in TDD rappresentano un futuro utente della tua API, anche prima che il codice esista. Pertanto, è meno probabile che tu scriva codice che non è necessario, con un'API ragionevole, mentre proteggi costantemente qualsiasi codice che hai già scritto.

I test non sono lì per assicurarti di scrivere il codice che vuoi scrivere. Sono lì per assicurarti che tre anni da oggi , non accidentalmente cambi il modo in cui il codice funziona attraverso un cambiamento apparentemente non correlato, causando difetti incomprensibili.

I test sono un'assicurazione contro il futuro. Mai rimuovi i test.