La cosa buona è che ti rendi conto che il tuo codice sotto test ha bisogno di assistenza. Piuttosto che implementarlo subito, crea un'interfaccia e usa i mock per assicurarti che i tuoi test stiano codificando il codice corretto. Dopo aver superato questi test, puoi passare all'implementazione del codice su cui si basa.

Stub e mock possono essere usati per simulare la funzionalità che non è ancora stata modificata / implementata. Possono anche aiutarti a risolvere le dipendenze che causano questo tipo di "reazione a catena".

D'altra parte, forse mantenere l'unico test (fallito) che guida il cambiamento successivo è l'approccio migliore.

Altri test mirati al codice che si basa su nuove funzionalità possono essere disattivati temporaneamente in quanto non sono realmente rilevanti a questo punto, ad es. nel tuo caso, disabilita i test per X fino all'implementazione di Y ecc.

In questo modo puoi concentrarti solo sul prossimo cambiamento, che è quello che vuoi, penso.

stop

Sembra che potrebbero esserci due problemi separati qui:

1. hai dimenticato alcune storie e scenari di test e non li hai scoperti finché non hai iniziato a lavorare su un particolare scenario di test e / o

2. stai effettivamente facendo test unitari, e non TDD feature testing

Per # 1, stop , torna indietro e aggiorna le storie e gli scenari di test, quindi ricomincia da capo con uno scenario diverso.

Per n. 2, stop e ricorda che stai testando le funzionalità, non le unità, quindi utilizza i mock per sorvolare le altre interfacce e / o implementa più codice per fare passare il test senza aggiungendo nuovi scenari di test. Ciò presuppone che non manchino scenari di test, ma invece - e questo è molto comune - test di unità conflittuale e TDD.

Questa è una grande domanda e una GRANDE frustrazione anche per me con TDD. Mi sembra che TDD manchi in questo scenario in cui non hai modo di sapere quali componenti di livello inferiore o funzionalità ti serviranno prima di iniziare a sviluppare.

Personalmente ho scoperto che TDD funziona solo se sai esattamente cosa devi fare e cosa devi chiamare per eseguire una funzione. Gli sviluppatori non sempre sanno tutto prima di iniziare, quindi ho trovato che il modo migliore per me per mitigare la situazione che descrivi:

Prototype

Quando realizzo semplici app prototipo per esplorare e scoprire metodi e approcci a un problema tecnico, scopro un sacco di lavoro sulle gambe e tolgo la ricerca prima di iniziare. Anche la progettazione e la stima diventano molto più semplici.

Se il prototipo deve essere così coinvolto da diventare l'applicazione, allora ti esorto a non fare la cosa pigra e comunque a costruire test unitari per il tuo prototipo dopo il fatto.

A questo punto dovresti conoscere meglio l'API di livello inferiore ed essere in grado di simulare con successo l'API di livello inferiore nei componenti di livello superiore.

Dipende dal tipo di test che stai scrivendo mentre fai TDD.

Il modello classico è quello di scrivere test unitari e utilizzare mock o stub per disaccoppiare il test dalle altre "unità" di codice.

Ci sono molti altri modelli alternativi come ATDD in cui il test è uno stack completo o un test quasi completo. In questo caso specifico, i test di scrittura affermano che il comportamento del programma richiesto non è una singola unità di codice, pertanto non si scriveranno altri test. Otterrai l'attrezzo per il roundtrip per soddisfare il test. Quindi aggiungi altri test per altre funzionalità / comportamenti.