[OJFord]

That probably works well when you've already established a good baseline, but when tests barely exist (or greenfield) or they're crap, I find it can be a real slowdown to try to test something you know you should.

Especially if there's something not entirely straightforward about it, like you need to figure out a way to instrument/harness something for the first time so that you can actually test against it. (Arguably inherently doesn't happen with unit tests though I guess.)

[diggan]

> like you need to figure out a way to instrument/harness something for the first time so that you can actually test against it

Indeed, and sometimes it's not worth to figure out, but sometimes it is. For example, if you have a piece of code that haven't changed since the beginning, and there been no bugs stemming from that code, adding tests to it is kind of futile unless you already know it has to be refactored soon.

On the other hand, if you join a existing project with almost no tests, and for the last N months, that code is responsible for introducing lots of bugs, then it's probably worth it to spend time building some testing infrastructure around the project with that part first up to be under lots of tests.

Basically, if the calculation shows that you can save more time by not having those bugs, you have some budget to spend on making the tests work well for that part.

[anymouse123456]

> I find it can be a real slowdown to...

Not OP, but this is the vibes approach I often use (and believe they're advocating for).

If it feels painful to add a new test, it's likely time (or nearly time) to make adding tests, or at least that test easier.

I've found that once it's easy to add tests, new tests often start appearing, so that first effort can be some of the most high-impact work available to me.