Design for Testability is a well-known topic in digital logic. The idea is that it is difficult to exhaustively exercise some hard-to-reach parts of complicated combinational logic unless seams are created, and then test vectors can be injected (where these seams are called boundary in electronic design).(Disclaimer: My education only touched lightly on digital design, and did not include coursework in DFT. The description above is from my impression, which may contain inaccuracies.)Test Drive Development as a software methodology compels software programmers to follow a Red-Green-Refactor approach. However, it does not specifically spell out how that code should have been written; it just points out a ritual that is good for ensuring that there are tests whose results change based on the presence of the most recent code change.It is widely believed that Test Driven Development is an indispensable aid to achieve Design for Testability in software. However, on a philosophical discussion (i.e. which is more fundamental), would Design for Testability be closer to the objective?By separating TDD and DFT, I am wondering if there are other methodologies equally capable of inserting the right seams/boundaries into a software architecture to enable the same level of comprehensive (deep-reaching) test coverage.
Is Design for Testing (DFT) more important than Test Driven Development (TDD) in principle?
architecture;refactoring;tdd;development methodologies