Unless you're designing and writing code against a predefined spec/RFC, I really don't feel like strict adherence to TDD is beneficial.

To me, that's partly the point. If you can't write the tests because the spec is wrong/contradictory/woolly/absent then that's a problem with the spec. Test Driven Development requires a solid spec, otherwise it's a non-starter.

I agree up to the point that you're building to spec because someone said you need a certain endpoint just because they thought it feels good. I don't think everything gets done in design meetings and I think there needs to be some relatively well thought out code written before you say "ok here's our API spec".

Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

I think there is a chicken-and-egg problem in this discussion and you all are talking about different layers of tests.

When designing an API is beneficial to write demo usage code. Like the synopsis part in a CPAN module. These can be tested against proof of concepts. That's the nucleus of the project.

When adjusting the spec you need to adjust those demos, hence code and test suite grow in the process.

After those are sufficiently stable you start wiring the POCs into modules with more specific unit tests, for instanceto cover edge cases.

But the tests you wrote while designing the API are already there.

You may have decided to change the internal architecture in the middle and split the code into multiple dependend modules behind the API. Different modules will have different unit test suites.

For me it's an iterative process, but this first layer of API tests will stay quite stable while the POCs will only be kept for historical reasons.

These API tests are the first tiny eggs if you want...

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
Wikisyntax for the Monastery}

Code needs to develop organically and allowed to form its own flow instead of being hammered into a predefined hole of a certain shape

This definitely resonates with me and the way I tend to create things. I'm not suggesting that I do it the correct or best way but, for better or worse, it is how I usually go about things.

As an example, I've just finished writing an email editor in JavaScript and Perl. The 'spec'¹ was that it has to be easy for a non-techie user to assemble components of an email (images and rich text), store those atomically and not in parts as I am using temporal tables. The stored data needs to be able to be edited at a later date and when sent out as an email, render reasonably well on Outlook for desktop and K9 for Android (I find if an email renders OK on both of those it will be reasonably alright on most email clients).

Other than that, the 'how' of the implementation or the 'what' of the appearance I had no idea.

I started off with the bit that I thought would be most difficult - the JavaScript rich text editor. I created something that did the basic formatting but also realised that execCommand is deprecated. I asked ChatGPT for help with what to use instead and it suggested Quill along with other options. So my focus changed from creating my own editor to integrating a pre-existing one. Then I had to solve the problem of adding blocks of rich text along with images and being able to drag and drop them to change order. All very different challenges to those I anticipated when I first took fingers to keyboard.

From there, I found that the HTML output from Quill is unnecessarily verbose. ChatGPT again to find DOMPurify to clean up the HTML before it is passed to Perl and stored in a database - there is still some HTML cleaning needed by Perl before sending out the emails but that differs depending on whether it is going to be a preview in the browser or sent out as an email.

The whole process from first key press to fully functioning system took about 4 days working just a few hours per day. I doubt (but don't know for sure) that I could have completed this in that time if I had written tests first. The only test it seems to need (and I'm open to being persuaded otherwise) is that allows people to create an email and that the email renders OK after being sent out. I certainly didn't envision what it was going to look like or the finer details at the start. It evolved organically.

¹ - This 'spec' existed nowhere other than in my head. This post is the first time it has been articulated.

Yea what I've been trying to get across in this thread but apparently failing to do so is that it's a waste of time to write tests for a POC (unless you have like, a wrapper around a low level HTTP client that you have say, a GET and POST method, there's nothing wrong with writing simple tests for that since that's not going to change) until after you've gone through enough review iterations to confirm with all involved that everything looks good. If something comes up after that, I think it's a scope change and an entirely different can of worms.

For personal projects I feel like a hard spec outside of a braindump of what you want to do really hinders you even more. Unless you have a good deal of experience in the domain you're working in I feel like you end up "prematurely optimizing" your API ergonomics because you've written out a bunch of API endpoint/method definitions without letting a workflow emerge.

Long story short, make it work, make it clean, make it fast.

Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past