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.
@kentbeck I think it's interesting that there is a common perception that TDD discourages thinking about things ahead of time. I suspect that this perception comes about because people often show TDD without the thinking process, and I think that happens because of how amazing it is that you can get away with very little up-front thinking when using TDD, and people teaching it want to show how cool that is. However, I think that also leads to some backlash because it seems like a waste of time.
@vcato I think it's not so much that TDD discourages thinking earlier as that TDD enables thinking later, when there is more information.
@kentbeck Yes exactly, and I think the enthusiasm for demonstrating how it enables thinking later makes it where many people tend to just show that aspect when teaching TDD. However, the student ends up saying to themselves "but it would have saved a lot of time to have thought this through more up-front", and therefore leading them to think that TDD will be slower.
@kentbeck Its behind a paywal :(
@ginsterbusch it’s in the free portion of the newsletter. Other non-subscribers are seeing it. Lmk if you’re still having trouble.

@kentbeck the overlay jumps up and blocks further reading as soon as you scroll down.

might be different for its original creator (ie. test with a private browser window eg. in Firefox), but here, it looks like a paywall to me.

@ginsterbusch click the Continue Reading button.
@ginsterbusch or, even better, "Subscribe".
@kentbeck Nope. Too lazy to get yet another account to a platform I dont use ;)