L'implementazione ovvia di TDD significa prima il codice, test dopo?

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

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

Do you know a book or blog post saying just that?

Direi che il libro di Beck dice proprio questo.

Continua dicendo

However, by using only Obvious Implementation, you are demanding perfection of yourself. Psychologically, this can be a devastating move. What if what you write isn't really the simplest change that could get the test to pass? What if your partner shows you an even simpler one? You're a failure! Your world crumbles around you! You die. You freeze up.

Come si può far passare il test scrivendo il codice se non esiste prima del codice?

Ovviamente non ci sono regole dure e veloci qui, dopotutto eravamo agili quindi possiamo e dobbiamo adattarci man mano che procediamo con iterazione:)

In parte dipenderà dalla semplice operazione, e man mano che pratichi TDD troverai sempre cose che hai testato male o che in realtà non sono state testate, è tutto parte della curva di apprendimento.

Inoltre, non dimenticare che TDD ti permette di testare l'interfaccia e l'implementazione prima di trasferirla sul codice live.

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 passando attraverso il codice una o due volte e sei mesi più tardi quando cambi qualcosa che puoi fallo con più sicurezza e di nuovo nella sandbox dei test.

Ovviamente, i test non significano che tu 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, no- rischio di cambiare hai più sicurezza e libertà durante lo sviluppo.

Se stai davvero cercando di ottenere una buona copertura e una qualità più elevata, sbagli di fianco a più test per iniziare, mentre pratichi TDD sempre di più svilupperai il tuo senso del livello di copertura di cui hai bisogno.

Ho appreso che per un codice triviale non dovrebbe esserci alcun unittest.

esempio: se si dispone di un metodo java getter / setter che associa un metodo a una variabile locale, un non-ticket per questo sarebbe eccessivo.

potrebbe essere questo è ciò che l'autore intende con

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