TDD solo i dettagli di implementazione o il comportamento?

-4

Quando stavo sviluppando un'app per console l'algoritmo era il seguente:

  1. prima crea una directory temporanea
  2. quindi chiama un altro comando che creerà un file xml all'interno della directory temporanea
  3. quindi leggi quel file xml ed estrai un nome da esso
  4. infine rinomina questa directory temporanea con il nome estratto da xml

quindi uso TDD dall'esterno e inizio a scrivere il test di accettazione. ma sono ancora confuso su cosa testare.

  1. Devo testare ogni passaggio del suddetto problema per testare se un file temporaneo viene creato o meno per verificare cosa succede se si verifica un'eccezione IO, quindi per verificare se eseguendo l'altro comando produci un xml quindi prova se xml contiene un attributo "nome" ecc.
  2. O per verificare se dopo aver eseguito l'app della console viene creata una cartella con solo un xml?
  3. come organizzare la mia suite di test se ho intenzione di testare il mio algoritmo passo dopo passo
posta Mostafa Darwish 16.05.2018 - 19:55
fonte

1 risposta

1

A mio parere, ci sono 2 dipendenze: IO e XML. In tal modo, puoi avere 2 interfacce per quei componenti iniettati nell'app principale. Con questo, puoi falsificare le dipendenze e creare test unitari per la tua app principale. Una volta sviluppata la funzionalità, è possibile creare test di integrazione o di accettazione sull'intero sistema.

Per riassumere, cosa faccio quando I TDD:

  1. Test unità in errore.
  2. Codice di produzione
  3. Se manca qualcosa, torna al punto 1.
  4. Scrivi test di integrazione / accettazione / e2e.
  5. Se devi modificare il codice di produzione, torna al punto 1.

Disclosure: non ho ancora troppa esperienza in TDD.

    
risposta data 16.05.2018 - 22:46
fonte

Leggi altre domande sui tag