Design per testabilità è un argomento ben noto nella logica digitale. L'idea è che è difficile esercitare in modo esaustivo alcune parti difficili da raggiungere della complicata logica combinatoria a meno che non vengano create cuciture, e quindi i vettori di test possono essere iniettati (dove queste cuciture sono definite "limite" nella progettazione elettronica).
(Dichiarazione di non responsabilità: la mia educazione ha toccato solo leggermente il design digitale e non includeva i corsi in DFT. La descrizione sopra è dalla mia impressione, che potrebbe contenere imprecisioni.)
Test Drive Development come metodologia software obbliga i programmatori di software a seguire un approccio Red-Green-Refactor. Tuttavia, non specifica in modo specifico come dovrebbe essere stato scritto quel codice; indica solo un rituale che è buono per garantire che ci siano test i cui risultati cambiano in base alla presenza del più recente cambio di codice.
È opinione diffusa che Test Driven Development sia un aiuto indispensabile per ottenere il design per testabilità nel software. Tuttavia, in una discussione filosofica (vale a dire più fondamentale), Design for Testability sarebbe più vicino all'obiettivo?
Separando TDD e DFT, mi chiedo se ci siano altre metodologie ugualmente in grado di "inserire giunzioni / confini giusti" in un'architettura software per consentire lo stesso livello di copertura di prova completa (profonda).