Posso iniziare con un test di unità passanti?

Naviga le tue risposte
6

Le regole dello zio Bob per TDD sono specificate qui.

  1. Non sei autorizzato a scrivere alcun codice di produzione a meno che non lo sia effettuare un test pass
  2. Non ti è permesso scrivere più di un test unitario di quanto sia sufficiente a fallire; e fallimenti di compilazione sono fallimenti.
  3. Non ti è permesso scrivere più codice di produzione di quanto sia sufficiente per superare il test dell'unità fallita.

Ma è corretto scrivere una serie di test che passano non appena il test viene compilato? Ad esempio, un test che asserisce null e l'impl di default di un metodo che sto test restituisce null. Sto facendo qualcosa di sbagliato facendo questo? Dovrei saltare al primo test che fallirà o è ok scrivere test che passino automaticamente per primo?

    
posta Daniel Kaplan 09.03.2013 - 01:15
fonte

2 risposte

12

No, perché è possibile scrivere un test che inavvertitamente passa quando dovrebbe effettivamente fallire.

Ecco perché lo fai fallire prima, in modo che tu possa dimostrare la transizione da uno stato fallito a uno stato passato dove stai testando la funzionalità effettiva che desideri, piuttosto che avere un test fasullo che passa e ti fa pensare che il tuo codice funzioni effettivamente, quando in realtà non lo è.

    
risposta data 09.03.2013 - 01:17
fonte
14

Dipende.

Se stai scrivendo un software per risolvere un problema aziendale o produrre uno strumento utile, allora sì, puoi scrivere un test che passa automaticamente.

Se, d'altro canto, stai scrivendo software per eseguire un'osservanza religiosa nella Prima Chiesa confessionale del TDD, allora no, non ti è permesso farlo. E probabilmente dovresti prendere un momento di auto-flagellazione per aver persino fatto la domanda.

    
risposta data 09.03.2013 - 06:15
fonte

Leggi altre domande sui tag

Evitare problemi durante la copia del codice Creazione di un nuovo formato di file: scrivere prima il codice o la documentazione?