TDD (Test-Driven Development)

Test-driven development inverts the natural order: write the test before the code — specify precisely what success looks like, watch it fail, then build until it passes. The point is not the tests; it is the thinking the order forces. Requirements become executable before they become assumptions.

What It Is

In TDD, development proceeds in a red-green-refactor loop: write a failing test that specifies the desired behaviour (red), write the minimal code that passes it (green), then improve the code's structure without changing behaviour (refactor), and repeat. The practice disciplines definition — you cannot write the test without deciding exactly what 'correct' means — and produces, as a by-product, a comprehensive suite that runs with every change. Its sibling, BDD (behaviour-driven development), extends the idea outward: acceptance criteria written in shared, executable language that business stakeholders can read and agree on before construction.

Why It Matters to You

TDD's relevance to executives is as a proxy for engineering rigour rather than a practice to mandate (prescribing methodology to engineers rarely ends well; asking for its outcomes does). Teams that test-first produce code with defect rates and change-safety profiles that retrofitted testing rarely matches — the tests are the requirements, kept honest. The adoption question in due diligence: what fraction of the codebase is under test, and does new code land with its tests, or do tests 'come later'? The second answer, sustained, means later never.

When You'll Meet It

In engineering culture assessments and quality discussions. Listen for whether tests are spoken of as part of the work or as overhead to be scheduled — that sentence tells you the defect future.