1

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.

Improve this question
5
  • 1
    Closer to what objective? TDD isn't about testing nor is it about testability. TDD is a development methodology, it tells you where to start writing code, which code to write next, when to stop writing code. In TDD, design emerges organically. The theory is that if you write the tests first, it is unnatural to write convoluted tests; if you are met with no constraints, you will naturally write the simplest test possible.
    – Jörg W Mittag
    Commented Feb 25, 2017 at 12:37
  • 1
    Since you are then tasked with making the test pass, the only possible way to write your code is to insert the seams implied by the simple test. But that is a consequence of TDD, not an objective. In TDD, you don't "design", the design just "happens".
    – Jörg W Mittag
    Commented Feb 25, 2017 at 12:37
  • Ah, I think I understand. By "objective" you mean "testability"?
    – Jörg W Mittag
    Commented Feb 25, 2017 at 12:38
  • @JörgWMittag testability!
    – quintumnia
    Commented Feb 25, 2017 at 13:54
  • @JörgWMittag: That a software design can emerge organically from the practice of TDD is one of TDD's biggest lies.
    – Robert Harvey
    Commented Jul 13, 2017 at 17:45

1 Answer 1

Reset to default
4

TDD is a software development methodology which requires your code to be tested and designed in such a way that it is tested. So the DFT is a consequence of following a TDD approach.

Having an easy to test design is not only better because you can test it, it is also better since you are forced to have a more modular design. By having "injection points" of data for testing purposes between component A and component B allows you in future to replace A by C. Otherwise, A and B might get tight coupled.

Thus, I would say that DFT is a general quality of the code, and one way (not the single way) of achieving it is using TDD.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.