Test-Driven Development or Test-Driven Design?

We all know that TDD means “Test-Driven Development” but I think of TDD more as a design tool than a testing tool.

That’s why I call it “Test-Driven Design”.

Imagine that you want to implement a software component to evaluate a mathematical expression. I’ll assume a class, but it could be anything (a function, etc.).

I would write a test first (in pseudocode, the specific language is not important here):

ExpressionEvaluatorTest:
    shouldEvaluateExpression():
        expressionEvaluator = ExpressionEvaluator()
        value = expressionEvaluator.evaluate(“-(3-2)/4^-2”)
        assert value == -16

This would be the very starting point for the creation of all the sub-components required to accomplish this task.

Writing the code for ExpressionEvaluator.evaluate() would reveal the need for an ExpressionParsingStrategyFactory class that would build() an instance of an ExpressionParsingStrategy class, which would execute() on the expression and generate an instance of an ExpressionParseTree class, whose evaluate() method would return the final value:

ExpressionEvaluator:
    evaluate(expression):
        parsingStrategy = ExpressionParsingStrategyFactory.build(SHIFT_REDUCE_PS)
        parseTree = parsingStrategy.parse(expression)
        return parseTree.evaluate()

Each class should be in turn TD-designed, so ExpressionParsingStrategyFactoryTest would drive the design of the ExpressionParsingStrategyFactory class, which would reveal the need for a ShiftReduceParsingStrategyTest, which would drive the design of a ShiftReduceParsingStrategy class, which would lead to an ExpressionTokenAnalyserTest, which would drive the design of the ExpressionTokenAnalyser class, which would make the class ExpressionToken emerge, whose design would be driven by ExpressionTokenTest.

So TDD is really a way of discovering the various components required by our code, and only those components. This enforces the S, the I, and the D principles in SOLID and leads to a better modularization than classic code-first methods.