Il tuo obiettivo è quello di rilasciare software con un certo livello di qualità. Supponendo che non si possa scrivere ogni singola riga di codice esente da errori o introdurre bug nell'intervallo tra quelle righe di codice, come si verifica se si è raggiunto quel livello di qualità? Che dire degli altri membri del team, che potrebbero non essere a conoscenza di tutte le implicazioni delle loro modifiche, modificando il software che hai scritto. Oppure tu stesso stai apportando modifiche 6-12 mesi dopo che non hai visto il codice? Devi essere in grado di testare il tuo software inizialmente e con ogni modifica che apporti ad esso, e le modifiche avverranno sempre in qualsiasi cosa tranne che nei progetti più banali.
Se consideri l'atto del design come l'atto di pianificare e definire la struttura del tuo software, quindi di produrre un software verificabile, devi avere una buona esecuzione sulla pianificazione e sulla definizione di tale struttura. Quindi quel tipo di seguito è che un attributo di buona progettazione è un software che puoi testare.
Tenete a mente quando la maggior parte dice "capacità di testare", non è un binario si o no, ma una scala lineare di quanto impegno ci vuole per ottenere un certo livello di certezza (95%, 99%, quasi mai al 100%) che il tuo software funzioni. Quindi, da un lato dello spettro, si imposta un test e si ha N persone che eseguono il codice per un'intera settimana in tutti gli scenari possibili, magari eseguire test di stress per eliminare le condizioni di gara. Dall'altra parte dello spettro, esegui una serie di test unitari che hai già prodotto come parte del tuo processo TDD, e in 10 secondi ottieni 287 OK e nessun errore.