Test-Driven Development or Test-Driven Design?

Andrea Laforgia — Sun, 14 Mar 2021 16:49:00 +0000

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.

Don't do Agile - be agile.

Andrea Laforgia — Tue, 25 Feb 2020 14:54:04 +0000

Cargo culting is defined as "an approach that copies an existing successful approach without properly analysing and understanding it."

I've seen way too many places cargo-culting Agile and ending up in what is normally called "Agile Theatre".

If you are just starting with Agile, or going through a transformation from Waterfall, be as little dogmatic as possible about which approach to follow.

Be careful about involving experienced, long-time Agile practitioners into an inexperienced team.

Don't let experts impose rules (or, even worse, "ceremonies") that nobody fully understands.

Teach your team what being agile really means, instead: what advantages and what disadvantages.

Start simple; then increase complexity if and when the team is ready to digest it.

Remember: there's no obligation to adopt Scrum. There's no obligation to adopt Kanban. Just let whatever works in your place mature as a process - don't even give it a name. Stick to whatever way of working enables you to be truly agile and produce the value you want and need.

Beware of Agile - be agile instead.

Remember that those big Agile gurus out there, who keep writing books and selling courses, have a vested interest in promoting Scrum or Kanban, or whatever other Agile paradigms. They have often set up a company that makes money off that. Not all of them are malicious but, ultimately, they don't care about what's best for you; they care about what's best for them.

Abandon the word "ceremonies".

Ditch estimates if you can: http://noestimates.org/blog/

DEV Community: Andrea Laforgia

Test-Driven Development or Test-Driven Design?

Don't do Agile - be agile.