Canon TDD -- I keep reading critiques of processes that aren't TDD, so I summarized the original definition.

https://tidyfirst.substack.com/p/canon-tdd

Canon TDD

What follows is NOT how you should do TDD.

Software Design: Tidy First?
@kentbeck wonder if this topic should be brought back and shared again at conferences with an audience of new younger devs that did not have the privilege to be there in the 90s 00s - by someone with some unquestionable credibility on the topic (like the person that shared the practice in the first place 🙂 )

@lukadotnet @kentbeck

"the person that shared the practice in the first place"

...

You mean @RonJeffries ?

😉

.

My experience, on Ward's Wiki, was that when @RonJeffries and crew showed up and insisted that Extreme Programming was the answer to everything, that "step one" of listing all intended tests was deemphasized. And examples, talks, and tutorials were done without it. Like The Bowling Game.

...

@lukadotnet @kentbeck @RonJeffries

I would say that there's nothing wrong with writing out your intentions to begin with. If that works for you.

But I would not consider it *necessary* or *mandatory*.

"But how will you know when you're DONE?!?"
seems to be a concern.

Well, when what you've built is sufficient to provide value, then you can consider it done.

Or if you can't think of anything more it should do.

...

@lukadotnet @kentbeck @RonJeffries

"But that could go on forever!"
some may object.

But this is not really a problem in my experience. I do have other things to do with my time.

As a sensible human being, I generally have some idea of roughly the kind of end result I wish to achieve.

And most often, along the way, I cut out and drop a number of my initial expectations, when I see that they are not really needed, to get something that is useful and valuable.

X

@JeffGrigg
nothing is mandatory. It's judgment all the way down.