Coder Legion - Recent posts tagged tdd

...that's so crazy, it might just work!

Wed, 25 Mar 2026 16:23:18 +0000

We've all seen it! The post in the early hours of the morning! I've done this, I've found that - “I solved the Riemann Hypothesis!”

You take a quick peek! Another one. Another late-night manifesto. Another graph that looks convincing. You’ve been click-baited before; an elegant PDF, triumphant tweets, the occasional YouTube video narrated in a voice that appeals. Most of us have trained ourselves to treat RH claims like unsolicited crypto tips: interesting in theory, radioactive in practice. We mute, we scroll, we protect our remaining brain cells.

So when I say I have a proof, I expect the eye-roll. I deserve it. The history of the problem is a graveyard of brilliant ideas that died quietly in the appendices of online preprints. But here’s the difference this time: I’m not asking you to believe me. I’m asking you to run the code.

Because the only honest way to answer the inevitable “that’s crazy” is to hand over a 100% falsifiable, machine-verifiable test-driven development (TDD) suite and say: break it.

Why the skepticism is rational

The Riemann Hypothesis is the ultimate mathematical catnip. It sits at the intersection of number theory, analysis, physics, and pure aesthetics. It promises to unlock the distribution of primes, the zeros of the zeta function, and a dozen other deep structures. For years it has resisted every attack. Every few months someone announces a proof, the community holds its breath for forty-eight hours, then the flaw appears — usually a hidden division by zero, an unjustified interchange of limits, or a computer check that only ran up to 10⁶ and not 10¹². The pattern is so reliable that the rational response has become a defensive reflex: ignore until peer-reviewed or independently reproduced.

I get it. I’ve done the same with these bold claims! But defensive reflexes can also become blind spots. What if the next claim isn’t a lone genius in a basement but an open, executable, modular framework? What if the proof isn’t a single 40-page LaTeX document but 1,900 passing tests, zero failures, and an architecture deliberately built so that anyone can swap in their own function, their own kernel, their own spectral operator — and let the mathematics itself be the referee?

That is exactly what this repository is.

The crazy part: a collaborative falsification engine

Here’s the part that still makes me grin like an idiot at 3 a.m.: the entire proof is now a plug-and-play test harness.

You don’t like the sech² curvature kernel? Drop in your own test function. The Bochner PSD checks and the Weil explicit-formula decomposition will run automatically.
You have a better gravity-well operator? Swap the polymeric Hilbert–Pólya matrix for yours. The PHO-representability gate and the Rayleigh-quotient bounds will immediately tell you whether it survives or breaks.
You think the Kadiri-Faber constants can be tightened? Edit _B_VK in analytic_bounds.py and watch test_42 re-run the monotonicity and asymptotic-vanishing assertions in real time.
You suspect an off-critical zero hides somewhere? Feed it to the triad governor (triad_scan) and it will compute the three-layer contradiction.

Every layer is isolated, every function is exported, every test is named and documented. The suite is not a black box; it is a laboratory. You are not a passive reader. You are now a co-experimenter. The math decides. Not me, not you, not any single ego. The code runs, the assertions fire, and the verdict is mercilessly binary: pass or fail.

That is the crazy part. And that is why it just might work.

What the harness actually proves

The architecture rests on a simple contradiction engine built around the Weil explicit formula and the positivity basin (Theorem B 2.0). Any admissible spectrum must keep the corrected functional $\widetilde{F}_2(T0; H, \lambda^*) \ge 0$. An off-critical zero injects a strictly negative contribution $\Delta A{\rm avg} < 0$ (Layer A, proven via continuous H-integral and Riemann–Lebesgue decay).

The triad governor scripts wires the three layers together and acts as an automated theorem prover. Feed it a hypothetical off-critical configuration and it returns a confusion matrix: no false rejections on-critical, no undetected anomalies off-critical. Every test in tiers 40–44 now passes with the new analytic bounds. The remaining 10 xfailed tests are honest finite-$N$ artefacts in the $\widetilde{F}_2$ equality conjecture — they are marked as such and do not affect the contradiction chain.

The suite currently runs numerous passing tests across 26 tiers. Zero failures. The warnings are only harmless integration warnings from scipy.quad on a deliberately pole-straddling support used for finiteness checks. Everything else is green.

Why this changes the game

Most RH claims are hermetic: you must trust the author’s calculation, the hidden lemma, the 400-line derivation that no one else has time to re-derive. This claim is the opposite. It is anti-hermetic. The code is public, the tests are public, the gaps were public, then closed in public, with every commit and every pytest run visible. You do not have to accept my word. You can fork the repo, replace the averaged_deltaA_continuous implementation with your own quadrature method, and watch the sign and decay tests re-run. If your version still passes, the envelope negativity survives. If it fails, the community now has a concrete counter-example to study.

This is not a proof by authority; it is a proof by invitation to falsify.

And that invitation is open to everyone — amateur, professional, physicist, number theorist, even the skeptic who started this article by reaching for the unfollow button. Swap in your function. Run the suite. Let the math decide.

The Endgame

Either the community finds the flaw (and we all learn something profound about where the current bounds break), or the suite survives every attempted break. In the first case, the RH remains open and we have a sharper diagnostic tool than we had yesterday. In the second case, the contradiction chain stands and the Riemann Hypothesis is settled.

I am not asking you to believe. I am asking you to test.

Because the craziest idea of all is this: after 165 years of solitary genius and lonely PDFs, the final proof of the Riemann Hypothesis might not come from one mind in one room. It might come from thousands of minds, each contributing one clean function, one tighter constant, one better quadrature — all judged by the same merciless, reproducible test harness.

For me, that is not crazy, it's how science is supposed to work.

TDD in the Age of AI: How Evals Can Benefit from Test-Driven Development

Mon, 09 Feb 2026 04:22:29 +0000

Test-Driven Development (TDD) has been a cornerstone of quality software engineering for decades. But as we enter the age of AI-assisted development and large language models, does TDD still hold relevance? The answer is a resounding yes—and perhaps more than ever before.

The Timeless Principles of TDD

At its core, TDD follows a simple cycle: write a failing test, write the minimum code to pass, then refactor. This red-green-refactor loop forces developers to think about requirements and edge cases before implementation. The result? Cleaner code, better design, and a comprehensive test suite that serves as living documentation.

TDD Meets AI: A Natural Partnership

When working with AI coding assistants, TDD becomes even more valuable. Here’s why:

Clear specifications: Tests provide unambiguous requirements that AI can understand and implement against
Verification layer: Tests act as a safety net to validate AI-generated code behaves correctly
Reduced hallucinations: When AI knows it must pass specific tests, outputs tend to be more grounded and practical
Iterative refinement: The red-green-refactor cycle works naturally with AI iteration

Evals: TDD for AI Systems

Perhaps the most exciting application of TDD principles is in the world of AI evaluations—commonly called “evals.” Evals are systematic tests designed to measure how well an AI model performs on specific tasks or criteria.

The parallel to TDD is striking:

TDD Concept	Eval Equivalent
Write failing test first	Define expected behavior before training/prompting
Minimum code to pass	Iterate on prompts or fine-tuning until eval passes
Refactor	Optimize prompts while maintaining eval scores
Test suite	Eval suite covering multiple capabilities

Applying TDD Mindset to Evals

Here’s how you can apply TDD thinking to your AI evaluation strategy:

1. Define Success Criteria First

Before crafting prompts or fine-tuning models, clearly define what success looks like. What inputs should produce what outputs? What edge cases matter? This is your “test specification.”

2. Create Measurable Evals

Write evals that can objectively determine pass/fail. This might include exact match comparisons, semantic similarity thresholds, or structured output validation. Avoid vague criteria that require subjective judgment.

3. Start with Failing Evals

Just like TDD, begin with evals that your current system fails. This ensures you’re building toward measurable improvement rather than just validating the status quo.

4. Iterate Incrementally

Make small changes to prompts or model configurations, run your eval suite, and observe the impact. Large changes make it difficult to understand what’s working.

5. Prevent Regression

Maintain a comprehensive eval suite that runs with every change. Just like unit tests catch regressions in code, evals catch regressions in AI behavior.

Practical Benefits

Teams adopting eval-driven development report several benefits:

Faster iteration: Clear pass/fail criteria eliminate guesswork
Better communication: Evals serve as a shared language between engineers, product managers, and stakeholders
Confidence in deployment: A passing eval suite provides assurance before shipping
Documentation: Evals document expected behavior in an executable form

Conclusion

TDD isn’t just surviving the AI age—it’s thriving. The discipline of writing tests first translates beautifully to the world of AI evals, where defining expected behavior upfront is crucial for building reliable systems.

Whether you’re writing traditional software, working with AI coding assistants, or building AI-powered products, the TDD mindset remains invaluable: specify behavior first, verify it works, then iterate with confidence.

The age of AI doesn’t diminish the importance of testing—it amplifies it.

The post TDD in the Age of AI: How Evals Can Benefit from Test-Driven Development appeared first on sudoish.

TDD Tests Assumptions, Not Just Code

Mon, 29 Dec 2025 15:36:37 +0000

In software development, the mistake that tends to cost more isn't the typical bug. It's building the wrong thing. A bug announces itself when something fails, and the fix is usually local. A wrong feature passes every test, ships, and only shows up when users don't use it. By then the design, the data model, and the code around it all rest on the misunderstanding. Some bugs break that pattern, such as corrupted data or a security hole, but they're the exception rather than the typical case.

Teams should be focused on preventing the delivery of features that don't match what users need, implementing requirements that were misunderstood, or discovering halfway through that the domain model was wrong. Test-Driven Development (TDD) is one solution to this problem, but it's often a very poorly understood concept, and even those who do understand it can still do TDD wrong.

Dan North, who coached teams in TDD, wrote in "Introducing BDD" that people's misunderstandings of TDD "almost always came back to the word 'test'." His answer was Behaviour-Driven Development. Practices like Gojko Adzic's Specification by Example put the same concrete examples in front of stakeholders before any code exists. BDD and Specification by Example are TDD's idea with better vocabulary, and this post is about that idea.

The promise of TDD is that tests guide design and catch bugs early. The reality, sometimes, is that teams write tests for features they don't yet understand, design interfaces around incomplete requirements, and spend hours on tests that get thrown away when understanding finally arrives. The resulting debate often gets heated. Advocates measure test coverage and celebrate red-green-refactor. Skeptics count rewritten tests as waste. Both sides miss what actually happened: when done right, those rewritten tests forced understanding before the wrong system got built and delivered. When done wrong, they were just ceremony.

Much of TDD's value isn't in the tests. It's in the understanding that writing them demands.

Testing Assumptions, Not Just Code

Business-Rule Tests State Assumptions

Most discussions frame TDD as a code quality tool: write tests first, implement to pass, refactor for quality. Coverage metrics become the measure of success. But every test also encodes assumptions about user needs and business logic. When you write a test asserting business rules, you're stating assumptions about how the system should behave, and not just your assumptions as a developer but the ones baked into the requirements themselves. A test can't check those assumptions against users on its own. Writing it makes them concrete enough to check, against the codebase and against someone who knows the business.

Not every test carries business assumptions. Small tests around a class's collaborators mostly serve design, so the argument here is about the tests that assert business rules. In outside-in TDD, those are the first test or two for each new rule, written at the rule's boundary before you know which classes you'll need. A developer who starts inside-out from a helper class still gets TDD's small steps, but not this gain. Even these tests have a limit. They can catch a requirement that was misunderstood, not one that was wrong to begin with, because whether users value a premium discount at all is a question for prototypes and users.

Writing the Assertion Forces the Choice

For those business-rule tests, timing is the gain. Writing the test first means you don't build for days before discovering misalignment, which is what happens when tests come at the end of a feature or not at all. You might find that an entire scope of work needs to go back for reconsideration, and finding that on day one is obviously better than finding it on day ten.

Consider a test asserting that CalculateDiscount(customer) returns 15% for "premium" customers. That test encodes assumptions about what "premium" means, what discount they deserve, and whether discounts even work this way. Discovery can happen immediately, because writing the test forces you to define "premium" concretely. You might realize the customer object has no tier field, or that the pricing service doesn't support percentage-based discounts, or that the requirement contradicts existing business rules.

Even the expected value forces a choice. On a $100 order that already carries a 10% promo code, is the answer $85, $76.50, or $75? Implementation code picks one too, as a line of arithmetic. The developer writing it is thinking about how to calculate, not about what the answer should be. An assertion asks for the answer itself. Working out $76.50 by hand is the moment you notice two discounts are stacking, so the choice gets made knowingly before any implementation begins.

That only helps if the choice reaches someone who knows the business. The habit that makes it work is taking any assertion you had to guess at to the product owner before moving on. TDD doesn't supply that habit. It supplies the moment where the guess becomes visible to the developer.

The test's setup can expose the larger misunderstanding too. To build a premium customer for the test, you have to decide what makes a customer premium. If you ask, you learn early that product meant purchase history rather than a tier. If nobody asks, product clarifies it later anyway, and the test is where the correction lands, as one visible, reviewable edit rather than a hunt through the code. Early or late, the test change isn't waste. It's learning captured before shipping wrong behavior.

A wrong assumption found before implementation costs a conversation, and found after, it costs the conversation plus the code built on it. Tests force specific questions that conversation alone often leaves unasked, because an assertion needs an exact input and an exact expected output where a requirements discussion can stay abstract.

Test-First Makes the Question a Default

Other routes can surface the same guess. A careful developer writing code first can meet the same question, and an example card in a Specification by Example session forces the same choice. TDD's claim isn't that only a test can force the choice. It's that a test-first habit forces the choice every time a developer starts a new rule, as a default rather than a matter of care, including on teams that never hold those sessions. It also reaches rules no session thought to raise, like how a premium discount stacks with a promo code, because those only appear when someone writes out the specific case.

Rewrites Are Learning Unless They Track Implementation

Skeptics still count the rewrites as waste, and some test code will get thrown away. Mocks and implementation details in a test encode their own assumptions, and some of those only get checked by building the code. That's fine. A little code waste is a small price compared to the larger waste of building the wrong system because critical misalignments went undiscovered. It stays little when tests written under uncertainty are few and coarse, so a rewrite touches a handful of assertions rather than a suite.

When large test rewrites happen repeatedly, though, they might signal something else. The tests may be coupled to implementation details rather than behavior, so every internal change breaks them. Or the developer who wrote them was going through the motions rather than asking what the code should do. The trigger tells you which. A rewrite prompted by a stakeholder's answer or a newly found domain fact is learning, and a rewrite prompted by a refactor that changed no behavior is coupling.

TDD treated as a checklist rather than a discipline for understanding will produce tests that don't surface assumptions early. The waste isn't in TDD itself; it's in treating TDD as compliance rather than inquiry.

Stop Measuring Success by Tests

This reframing should change what we measure, but not by replacing one test metric with another. Using test coverage as a success metric is a distraction. Measuring "assumptions caught" would be too. Value delivered is the only meaningful measure of success.

One signal connects value back to the tests: features that return for rework because a business rule was misunderstood. Compare one team's count before and after it adopts the habit. That's a team signal rather than proof, since rework also comes from stakeholders changing their minds. Don't compare rules that got a business-rule test first against rules that didn't. Developers may write tests first more readily for rules they already understand, so that comparison flatters the habit.

Coverage metrics can still provide useful insight into quality gaps, but think in terms of use case coverage rather than line coverage. Are the critical business scenarios tested? Are the edge cases stakeholders care about covered? That's a different question than "what percentage of lines have tests?"

Tests are a tool, not an outcome. When teams treat coverage percentages as goals or count rewritten tests as waste, they've confused the means for the end.

The test suite does have secondary value as documentation that new developers can read to understand system constraints without digging through old conversations and tickets. But that's a side effect, not a success metric.

Match the Test to How Settled the Requirement Is

Which tests to write first depends on how risky the assumption is, and how to write them depends on how settled the requirement is. The riskiest assumptions tend to sit in:

Business rules. How discounts work, what triggers notifications, when transactions are valid
Edge cases stakeholders haven't considered. What happens when the cart is empty? When the user has no purchase history?
Data validity assumptions. What "valid" input looks like, what formats are acceptable, what happens with missing fields

The same test-first habit serves two different purposes depending on how settled the requirement is:

Requirement	What the test is for	How to write it	When the test changes
Clear and stable	Checking the implementation against an agreed rule	Fine-grained tests around the logic, kept for the long term	Something broke a commitment, so fix the code
Uncertain	Exposing the assumptions inside the rule	A few tests at the business-rule boundary, asserting outcomes a stakeholder can confirm, light on mocks	Understanding moved, so update the test and keep going

Classifying a requirement as clear is itself an assumption, and the falsely settled ones are where teams build the wrong thing. If writing the first test for a "clear" rule raises a question the ticket can't answer, the rule belongs in the uncertain row.

How settled the requirement is matters more than the usual debate about test-first versus test-after. A study by Davide Fucci and colleagues of 39 professionals found that the order of test and production code had no important influence on code quality or productivity, while small, steady steps did. Small steps are a benefit TDD brings to the code itself, separate from the understanding this post is about.

That study scored code against predefined stories on small coding tasks. The requirements were already specified, so there was nothing to misunderstand. Its finding covers code quality and productivity, not catching misunderstood requirements. For catching them, the case for writing the test first rests on the mechanism the discount example showed rather than on data. An assertion written before the code has to state the expected value with no code to copy it from, while one written after can simply record whatever the code already does.

The better question is what assumptions you're making about user needs and how to validate them fastest. Sometimes that's writing a test first, other times it's building a prototype first, and sometimes it's showing mockups to users first. The goal isn't perfect tests. It's validated understanding.

The most overlooked value of TDD isn't in the tests that pass. It's in the tests that change because an assumption turned out to be wrong.

Tests Are Commitments to What You're Building

Writing the test first forces a question: what should this code actually do? That question demands understanding before implementation. The passing assertion represents a commitment: this is the contract we're building to. Implementation honors that commitment by making the test pass.

When tests change during development, you're realigning based on discovery. When tests fail after changes, they're surfacing broken commitments that need attention. The discipline isn't about tests. It's about starting with understanding, securing genuine commitment to what you're building, and then honoring what was agreed.

Building the wrong thing is the more expensive mistake. TDD's first business-rule tests address the misunderstood-requirement half of it by forcing clarity before code, but only when practiced as inquiry rather than compliance. Tests that surface wrong assumptions early are valuable even when they get rewritten. Tests written as ceremony produce waste without insight.

In practice, that means:

Treat coverage as a diagnostic for missing use cases, not a goal
Read a rewritten test as an answered question, not as failure
Write tests to the requirement's state, coarse and disposable while it's uncertain, fine-grained once it's settled
Measure whether you delivered what users actually needed, starting with how often features return for rework over a misunderstood rule

TDD isn't just a testing practice. It's a discipline for understanding.

[BOOK REVIEW] Beck K., Extreme Programming Explained (1999)

Mon, 22 Dec 2025 08:32:37 +0000

This is the teaser post of the original review that is pretty detailed, containing images and diagrams.

Beck K., Extreme Programming Explained (1999)

Extract

The book is only 1/5 about programming and 4/5 about organizational matters. The book covers all the core and corollary elements of what is nowadays called Agile. It accompanies the other 2 Beck's books on the subject: Planning Extreme Programming (2000) and TDD by Example (2002).

Contents

Summary
XP Notions Hierarchy
Values
Principles
Practices
Whole XP Team (Cross-Functional Teams)
Process Bottlenecks
Planning via Managing Scope
Testing
Design
Scaling XP

[VS] The book name is rather misleading. Roughly 80% of it is dedicated to organizational matters. This messes the book goals, makes absorbing the book material by engineering and managerial audiences hard.

The following purely engineering notions are explored in the book: Test-First Programming, Incremental Design, Automated Tests, Pair Programming, Ten-Minute Build, Code and Tests, Single Code Base.

The book is quite short. It consists of two parts: 'Exploring XP' (which describes practical, useful elements) and 'Philosophy of XP' (a series of essays on the subject). For practicality, my review does not cover the latter. However, it gets very interesting and valuable reading after you have internalized XP enough to absorb its roots.

The book sometimes uses mind maps to explain key concepts. The issue is those maps are practically unreadable. This review fixes that issue. Enjoy.

[VS]: XP (and later Agile) is not about software construction ("what to do"). It is about the elements of an organizational process ("how to do") that may or may not bring value to your specific software products.

Practically Waterfall is "what to do" and XP is "how to do" your Waterfalls.

Most of XP is pure common sense derived from production and marketing management practices 1. These practices were already well developed in organizational cultures 2 more advanced than those in Software Engineering at the time of the book's writing.

Internalize the core content of the book, consciously, selectively apply it in the daily practice and you get what many today calls Agile.

XP Notions Hierarchy

The XP notions - Values, Principles, Practices - are organized in the following hierarchy.

...continue reading at the original review.

[BOOK REVIEW] Meszaros G., xUnit Test Patterns (2007)

Thu, 13 Nov 2025 08:47:56 +0000

This is the teaser post of the original review that is pretty detailed, containing images and diagrams.

Meszaros G., xUnit Test Patterns (2007)

Extract

This book is essential language-agnostic source to make your TDD delivering principal values: maintainable test code, joyful SUT refactorings, and zero product defects.

Contents

Summary
Concepts
- Goals of Test Automation
- Testing Philosophy
- Principles of Test Automation
Practice
- Test Smells
- Test Automation Strategy
- xUnit Basics
- Test Fixtures
- Result Verification
- Test Doubles
- Test Organization
- Testing with Databases
  - Issues with Testing with Databases
  - Testing without Databases
  - Testing the Database
  - Database Patterns
- A Roadmap to Effective Test Automation
  - Test Automation Difficulty
  - Roadmap to Highly Maintainable Automated Tests
- Remaining Patterns

Summary

While TDD by Example is more conceptual, practically demonstrating only TDD cycle, this one presents a much wider and very practical body of knowledge a software engineer must not miss.

[INFO] [xUnit](https://en.wikipedia.org/wiki/XUnit) is the family of unit testing frameworks implementing unified specific approaches and test code patternsThe family includes test frameworks for Java, C#,, JavaScript, PHP to name a few.

Despite seemingly heavy, The book is effectively organized and is a pleasure to absorb using my reviewSkim the diagrams and maps, take 1-2 techniques you like most and start applyingWhen hungry again return for moreWith time the book becomes a good foundational reference on testing.

The review combines "Part INarratives" and "Part IIIPatterns" into a single space as they discuss the same at different level on granularityPart I introduces concepts, Part III provides implementation patternsOn top the review moves the more broad concepts (goals, philosophy and principles) up.

Concepts

Goals of Test Automation

Tests should (p. 84):

Help us to improve quality and understand the SUT.
Reduce (and not introduce) risk.
Be easy to run, easy to write and maintain.
Require minimal maintenance as the system evolves around them.

Testing Philosophy

(p. 94)

Write the tests first!
Tests are examples (of SUT usage)!
Usually write tests one at a time, but sometimes list all the tests one can think of as skeletons upfront.
Outside-in development helps clarify which tests are needed for the next layer inward.
Use primarily State Verification (p. 172, 525) but will resort to Behavior Verification (p. 531) when needed to get good code coverage.
Perform fixture design on a test-by-test basis.

Principles of Test Automation

(p. 102)

Write the Tests First
Design for Testability
Use the Front Door First
Communicate Intent
Don’t Modify the SUT
Keep Tests Independent
Isolate the SUT
Minimize Test Overlap
Minimize Untestable Code
Keep Test Logic Out of Production Code
Verify One Condition per Test
Test Concerns Separately
Ensure Commensurate Effort and Responsibility

Practice

Test Smells

continue at the original [review]

TDD: Barrier and Brilliance

Thu, 13 Nov 2025 08:47:52 +0000

TDD: Barrier and Brilliance

TDD stalled on Beck’s “no design before tests” flaw, but when paired with thoughtful design it flips costs into benefits—isolated complexity, minimal debugging, and cleaner interfaces shaped from the consumer’s view.

Kent Beck, who gave us both TDD and Extreme Programming, deserves credit as the pioneer whose vision shaped modern agile practice—even if his early framing carried the flaws natural to anyone charting new ground.

This is the short overview and conclusion induced by the insightful Test-Driven Development is Stupid writing. The colleague Geometrian rightfully (in my view) dismisses TDD for the same flaw I did in my Applying TDD Teaches Everything article and my review of Beck's TDD by Example book.

Here is a short list that would finally clarify the entire thing (hopefully).

The Barrier to TDD

Most developers who never adopted TDD were stopped by Beck’s original flaw: the notion of “no design before tests.” This single misstep, rooted in Extreme Programming 1, 2 undermined TDD’s credibility and turned many away before they could experience its real benefits.

The Cost of No-TDD

Those who reject TDD end up paying elsewhere:

They lack complexity isolation,
They are forced into endless debugging runs of the entire system, multiplying wasted time saved from not doing TDD, and
They miss the uniquely powerful design perspective TDD provides—shaping clean public interfaces as a consumer of their own code. Coarse "paper" designs like UML are required before TDD, but they can only touch the surface of consumer-facing API design. The main work in this department happens with TDD - it allows the engineer to feel and act as an API consumer, which fundamentally improves the implementation compared to what it would have been without TDD. This often leads also to updates of the coarse paper design solutions.

The Brilliance of TDD

Reversing the costs above reveals the true brilliance of TDD:

TDD provides the complexity isolation to the level manageable by humans - the main issue of people writing software.
TDD nearly eliminates the need for system-wide debugging. Instead of rerunning the whole application, you validate behavior in isolation, accelerating iteration and learning.
TDD is not just about correctness—it is a design instrument - finer and additional to careful UML etc. design. Writing tests first (once a design is thoughtfully established—e.g. UML class, sequence etc. diagrams) places you in the code consumer’s seat, ensures your public interfaces are clean and convenient for use, hiding the implementation details beneath. Unlike UML’s static sketches, TDD (again, upon design made) delivers executable, evolving API consumer feeling in an engineer writing the code - a code producer.