Ho letto il seguente post di Uncle Bob su TDD. Spiega che ci sono casi in cui il TDD non è necessario. Principalmente in un caso in cui i test e il codice sono entrambi molto specifici e il tuo codice non tende a algoritmi più generali.
Suggerisce che la logica dovrebbe essere TDDed, e tutto ciò che non è logico dovrebbe essere aggiunto a un livello umile. Ad esempio CSS. Verificare che una classe css sia 5px richiederebbe sia il test che il codice di avere 5px codificati in entrambi. Mentre i test diventano più specifici, il css non diventerà più generico, infatti anche questo diventerà più specifico.
Remember the TDD rule: As the tests get more specific, the code gets more generic. Every new test case makes the test suite more constrained and more specific. To make the new test case pass, the programmer strives to make the production code more general, not more specific....
...Indeed, you could write a program that reads the CSS and writes the tests. Such tests add very little value, and they certainly aren't written first.
Questo ha senso, ma mi sono imbattuto in un caso in cui la stessa logica poteva essere applicata, ma non sono sicuro se ho preso l'esempio nel post troppo lontano.
Ho una classe controller che ho applicato a TDD. Il metodo classes restituisce un nome vista come risposta. I metodi possono passare diverse variabili nella vista, ma il nome della vista rimane sempre lo stesso.
Il nome della vista sarà hardcoded nel controller e nel test. È quindi un test inutile (come nell'esempio CSS)? Poiché i test diventano più specifici per il mio controller, non ci sarà mai un caso in cui in qualche modo finirò per rendere il codice che genera il nome della vista più generico: sarà sempre codificato per restituire un nome specifico.
Se si tratta di un test inutile, dove dovrei inserire questo codice "umile"? Se il controller è visto come una classe che ha una logica (e quindi ha bisogno di TDD) e l'output di un nome di vista specifico è 'umile', come faccio a tenerne conto nel mio controller?
Nota: quando dico che il controller ha 'logica', intendo che ha logica testabile TDD, ad es. un controllore trasferirà i dati dell'utente a un modello, pertanto il controllore ha bisogno di test che garantiscano il passaggio dei dati corretti a un modello.