ALD and Test-Driven Development

In Architect-Led Development (ALD), tests do more than verify correctness. They define architectural intent, encode business decisions, and act as the primary control surface for safe change and AI-assisted delivery.

Tests as contracts See the test layers

In short: classic TDD drives code. ALD-driven TDD drives decisions and boundaries.

One-sentence framing

In ALD, tests are architectural contracts—written before implementation, owned by architects, and used to constrain behavior so implementations can evolve safely.

Contracts Decisions Role-based tests Refactor-safe AI-constrained

The core shift: from code correctness to intent enforcement

Classic TDD loop

  • Red → Green → Refactor
  • Tests verify implementation behavior
  • Primarily developer-focused
  • Often algorithm- or method-centric

ALD-driven TDD loop

  • Intent → Contract tests → Implement → Refine
  • Tests define what decisions must be true
  • Architect- and business-aligned
  • Role- and policy-centric
Key insight: In ALD, tests are written to eliminate ambiguity before any implementation exists.

Tests as architectural contracts

ALD treats certain tests as non-negotiable guarantees that define the behavior of a role.

What contract tests describe

  • Decision outcomes and invariants
  • Edge cases and failure modes
  • Required metadata (reason codes, audit data)
  • What must never change silently

What contract tests replace

  • Ambiguous acceptance criteria
  • Tribal knowledge
  • Interpretive story handoffs
  • Late-stage clarification and rework
Example: contract-style test names 
rejects_application_when_ltv_exceeds_policy_limit()
accepts_application_when_income_coverage_meets_threshold()
returns_reason_codes_for_compliance_reporting()
ALD rule: changing a contract test is changing policy. That change must be intentional and reviewed.

Tests define role boundaries

ALD uses tests to validate where responsibilities belong, not just how code behaves.

Role-scoped test suites

  • Each role has its own contract test suite
  • Tests stay small, cohesive, and intention-revealing
  • Uncomfortable tests signal misplaced responsibility

Architectural enforcement

  • Single Responsibility Principle enforced naturally
  • Interface Segregation emerges from test clarity
  • “Service blobs” are exposed early
Heuristic: if tests feel awkward or mixed, the role boundary is probably wrong.

Executable ubiquitous language

ALD tests are written in business language, making domain intent executable and durable.

Language-first testing

  • Test names read like business rules
  • DTOs and domain types appear in assertions
  • Error and reason codes are explicit

Why it matters

  • Tests double as documentation
  • Language drift becomes visible
  • Auditors and product owners can review behavior
DDD synergy: ALD turns ubiquitous language into executable truth.

Intentional test layers in ALD

ALD is opinionated about which tests matter most and why.

Contract tests (highest value)

Define role behavior and policy. Written first. Stable over time. Architect-owned.

Implementation unit tests

Support internal logic. Often AI-generated. Disposable during refactors.

Integration tests

Validate adapters and external systems. Kept thin and purposeful.

Guiding principle: strong contract tests reduce the need for brittle integration tests.

TDD as a safety harness for AI

ALD uses TDD to make AI-assisted development predictable, verifiable, and replaceable.

Without ALD

  • AI interprets intent implicitly
  • Behavior varies across implementations
  • Regressions are subtle and risky

With ALD-driven TDD

  • AI implements to explicit contracts
  • Tests prove behavior objectively
  • Implementations are swappable
ALD stance: do not trust AI with intent—constrain it with tests.

Summary: how ALD uses TDD

Classic TDD ALD-driven TDD
Tests verify code Tests define decisions
Method-centric Role-centric
Developer-owned Architect-owned contracts
Focus on correctness Focus on intent and governance
Refactors are risky Refactors are safe under contracts
Final takeaway: In ALD, tests don’t just validate the system—they are the architecture.