voiceofunreason

Mohammad Ghafari et al (2020) appears in the references, which is a good start.

I think this paper is best understood as an experience report: after reviewing [list of references], we thought this would be an interesting experiment to try, and here is a summary of our results and conclusions.

"Unlike Beck’s original three-phase cycle, AI-TDD does not assign Refactor to a dedicated persona."

If I ran the zoo, I'd have leaned toward the "many more much smaller steps" option, with at least two distinct persona for refactoring (and probably more than one distinct test writer as well).

But how much do you want to invest in a higher fidelity representation of "expert" TDD, given the lack of evidence that TDD is a significant improvement on YOLO?

Backups are boring. Restores, on the other hand, are often exciting.

My guess is that if you were building all of this from scratch, you would start with

- request-with-a-body

- idempotent-request-with-a-body

- safe-request-with-a-body

because the additional constraints induce properties that are extremely useful to general purpose clients ("I didn't get a reply to my idempotent-request-with-a-body, can I resend it without risking loss of property?")

Would someone then come along an introduce safe-request-without-a-body method? After all, we can already meet that "need" with safe-request-with-a-body and content-length: 0.

Think rfc-5789::PATCH - mechanically, it's just another request-with-a-body, but with more tightly constrained semantics. But general purpose components can take advantage of the additional properties, and so we introduce a "niche" method with tighter constraints.

Document resource manipulation is a common case, so we probably end up with a family of specialized methods, in much the same way that we have a bunch of WebDAV methods.

> I swear almost every critique of test driven development boils down to "I wrote a bad test".

It does seem that way - this one theme does drown out all of the other criticisms.

That said, (to first order) everyone's been "doing it wrong" for 25 years (give or take, there are lots of reasonable start dates to choose from).

Maybe "everyone" isn't the actually the problem, and we need to be open to alternatives like "our theory of what makes it work isn't very strong yet", "we oversold it", or "it was only ground breaking when compared with just-winging-it".

Render therefore unto Caesar the things which are Caesar's; and unto Claude the things that are Claude's.

Area Man Passionate Defender Of What LLM Imagines Test Driven Development To Be

My recommendation: you should probably start from _Working Effectively with Legacy Code_ by Michael Feathers.

The best "let's do something not trivial" TDD book is probably still _Growing Object Oriented Software, Guided by Tests_ by Steve Freeman and Nat Pryce.

Most of the "more than the basics" topics are the same kinds of practices that were considered "good design" whether you were using TDD or not. For example, Parnas 1971, Berard 1993, John Carmack 1998 ("Time is an input...."), and so on.

If you are interested in more than the basics on TDD, the right starting point is _Test Driven Development by Example_ by Kent Beck, which while a bit thin on examples actually covers a nice variety of more advanced topics (although not in great depth). If you are going this route, you should pair that with Beck's 2023 essay "Canon TDD".

Is there any prior art that defines covariant/contravariant tests in this way, or is Martin just borrowing language that sounds cool?

"I still find the skepticism around TDD weird."

A small community of programmers, with a disproportionately large audience, foretold that practicing test-driven development would produce great benefits; over twenty five years the audience has found that not to be the case.

Compare with "continuous integration" - here, the immediate returns of trying the proposed discipline were so good that pretty much everybody who tried the experiment got positive returns, and leaned into it, and now CI (and later CD) are _everywhere_.

As for what is gained, try this spelling: test driven development adds load to your interfaces at a time when you know the least about the problem you are trying to solve, which is to say the period where having your interfaces be flexible is valuable.

And thus, the technique gets criticism from both ends -- that design work that should have been done up front is deferred (making the design more difficult to change, therefore introducing costs/delays), and that the investment is being made in testing before you have a clear understanding for which tests are going to be sensitive to the actual errors that you introduce creating the code (thereby both increasing the amount of "waste" in the test suite, in addition to increasing the risk of needing test rewrites).

The situation is further not improved by (a) the fact that most TDD demonstrations are problems that are small, stable problems that you can solve in about an hour with any technique at all and (b) the designs produced in support of the TDD practice aren't clearly an improvement on "just doing it", and in some notable cases have been much much worse.

So if it is working for you: GREAT, keep it up; no reason for you not to reap the benefits if your local conditions are such that TDD gives you the best positive return on your investment.

"I call them 'unit tests' but they don't match the accepted definition of unit tests very well." -- Kent Beck, __Test Driven Development By Example__

The short version is that "unit test" did actually mean something (see Glenford Myers, __The Art of Software Testing__ or Boris Beizer, __Software Testing Techniques__), although it wasn't necessarily clear how those definitions applied to object-oriented programming (see Robert Binder, __Testing Object-Oriented Systems__).

The Test-First/TDD/XP community later made an effort to pivot to the language of "programmer test", but by the time that effort began it was already too late.

So I think you should continue to call your tests "tests" (or "checks", if you prefer the framing of James Bach and Michael Bolton).

As best I can tell - there's no historicity to the idea that "unit test" was a reference to the isolation of a tests from its peers; it's just a ret-con.

"REST is just pure bullshit. Avoid it like a plague."

No it isn't. Evidence: I'm reading this in a web browser.

"...REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them."

Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Yeah, _that_ is certainly plague bullshit.

I have yet to see an LLM + TDD essay where the author demonstrates any mastery of Test Driven Development.

Is the label "TDD" being hijacked for something new? Did that already happen? Are LLMs now responsible for defining TDD?