"Implementazione ovvia" di TDD significa prima il codice, dopo il test?

Io e il mio amico siamo relativamente nuovi TDD e abbiamo una disputa sulla tecnica "Implementazione ovvia" (da "TDD By Example" di Kent Beck). Il mio amico dice che se l'implementazione è ovvia, dovresti andare avanti e scriverlo - prima di qualsiasi test per quel nuovo comportamento. E in effetti il ​​libro dice:

Come si implementano operazioni semplici? Implementali e basta.

Anche:

A volte sei sicuro di sapere come implementare un'operazione. Vai avanti.

Penso che l'autore voglia dire che dovresti prima testare e poi "solo implementarlo" - al contrario del "Fake It ('Till You Make It)" e di altre tecniche, che richiedono passaggi più piccoli nella fase di implementazione. Inoltre, dopo queste citazioni, l'autore parla di ottenere "barre rosse" (test non riusciti) quando si esegue "Implementazione ovvia" - come si può ottenere una barra rossa senza un test ?.

Eppure non sono riuscito a trovare alcuna citazione dal libro che dice "ovvio" significa ancora test prima.

Cosa ne pensi? Dovremmo testare prima o dopo quando l'implementazione è "ovvia" (secondo TDD, ovviamente)? Conosci un libro o un post sul blog che dice proprio questo?

Sono d'accordo con la tua interpretazione - è ancora Refactor Red Green, solo con il bit Refactor escluso;)

Quindi, prima scrivi un test fallito, quindi implementa la soluzione ovvia invece di costruire lentamente un progetto di "il più semplice possibile".

Conosci un libro o un post sul blog che dice proprio questo?

Direi che il libro di Beck dice proprio questo.

Continua a dire

Tuttavia, utilizzando solo l'implementazione ovvia, stai chiedendo la perfezione di te stesso. Psicologicamente, questa può essere una mossa devastante. Cosa succede se ciò che scrivi non è davvero il cambiamento più semplice che potrebbe far passare il test? Cosa succede se il tuo partner ti mostra uno ancora più semplice? Sei un fallimento! Il tuo mondo si sbriciola intorno a te! Muori. Ti congeli.

Come si fa a superare il test scrivendo il codice se non esiste prima del codice?

Ovviamente non ci sono regole rigide e veloci qui, dopo tutto sono state agili, quindi possiamo e dovremmo adattarci mentre ripetiamo :)

In parte dipenderà dalla semplice operazione e, man mano che pratichi TDD sempre di più, troverai regolarmente cose che hai testato male o che in realtà non hai testato, fa tutto parte della curva di apprendimento.

Inoltre, non dimenticare che TDD ti consente di testare l'interfaccia e l'implementazione prima di impostarlo su live code.

Potresti sapere come implementare qualcosa, ma con quale frequenza scrivi una classe / metodo perfetto ecc. La prima volta senza alcune modifiche lungo il percorso o esaminando il codice una o due volte e sei mesi dopo, quando cambi qualcosa, puoi farlo con più fiducia e ancora nella sandbox dei test.

Naturalmente, i test non significano che scrivi il codice più correttamente la prima volta, ma le tue modifiche sono guidate dal test e i test diventano il primo client del codice e poiché i test sono molto economici e, soprattutto, nessun rischio di modifica hai più fiducia e libertà durante lo sviluppo.

Se stai davvero cercando di ottenere una buona copertura e una qualità più elevata, allora dai un errore a più test all'inizio, mentre pratichi TDD sempre più svilupperai il tuo senso del livello di copertura di cui hai bisogno.

Ho imparato che per un codice banale non dovrebbe esserci affatto unittest.

esempio: se si dispone di un metodo jetter getter / setter che associa un metodo a una variabile locale, unittest per questo sarebbe eccessivo.

potrebbe essere questo il significato dell'autore

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."