Questa è una domanda riguardante l'approccio fondamentale del TDD, quindi l'esempio qui sotto è il più semplice possibile che potrebbe far sembrare un po 'inutile; ma naturalmente la domanda si applica anche a situazioni più complicate.
Alcuni colleghi e io stiamo attualmente discutendo e provando alcuni metodi di codifica di base del TDD. Ci siamo imbattuti in domande su come gestire soluzioni a basso costo per i TC esistenti ma non esaustivi. In TDD si scrive un TC che fallisce, quindi implementa tutto ciò che serve (e non di più!) Per consentire al TC di passare. Quindi il compito da svolgere sarebbe quello di rendere il TC verde con il minor sforzo possibile. Se questo significa implementare una soluzione che utilizza la conoscenza interna del TC, così sia. Il ragionamento era che i TC successivi avrebbero comunque verificato la correttezza più generale, quindi la prima soluzione avrebbe dovuto essere migliorata allora (e solo allora).
Esempio:
Vogliamo scrivere una funzione di confronto per una struttura dati con tre campi. Il nostro confronto restituirà se i valori dati sono uguali in tutti e tre i campi (o differiscono in almeno uno). Il nostro primo TC scritto controlla solo se una differenza nei primi due valori viene rilevata correttamente: passa (a,b,c) e (a,b,c) e verifica il corretto rilevamento dell'uguaglianza, quindi passa (a,b,c) e (x,b,c) e verifica una corretto rilevamento della disuguaglianza.
Ora l'approccio economico dovrebbe anche implementare solo un confronto del primo campo, perché questo dovrebbe essere sufficiente per passare questo TC. Tieni presente che ciò può essere fatto perché sappiamo che i test successivi controlleranno anche l'uguaglianza degli altri due campi.
Ma ovviamente non sembra molto utile implementare solo una soluzione (più o meno) senza senso; ogni programmatore che lo fa lo farebbe con la consapevolezza di scrivere un bug. Ovviamente sembra più naturale scrivere subito un confronto decente nella prima iterazione.
D'altro canto, scrivere una soluzione corretta senza avere un TC che la controlli potrebbe portare alla situazione in cui un tale TC che verifica il comportamento più a fondo non verrà mai scritto. Quindi c'è un comportamento che è stato scritto senza avere un TC per questo (cioè, che non è stato sviluppato test-driven).
Forse un approccio corretto è quello di non scrivere TC così rudimentali (come quello che controlla solo il primo campo) in primo luogo, ma ciò significherebbe richiedere TC perfetti in prima iterazione (e, naturalmente, in situazioni complesse probabilmente uno non sempre scrivere TC perfetti).
Quindi come si dovrebbe trattare con TC rudimentali? Implementare una soluzione economica o no?