I just read the article, I agree with pretty much everything in there. Imo TDD (not really mentioned here but in the other article in the beginning) is still a good idea because it forces you to think about your design before getting bogged down into implementation details.

What often misses from such articles though is an example of how to get there. Nobody sets out to write bad code or brittle tests. So following along a codebase that used to suck and is slowly getting better would be great! Though I understand it's a much more involved exercise, I'm not holding it against the author.

Personally, I find that a couple weeks of TDD each quarter is enough of a boost to your design thinking to make a substantial improvement in how you design things. I don’t know how long a new engineer needs to do TDD to “get it” but I know for sure that you don’t need to do it for 10 years consistently.

If you’re really struggling to test a piece of code, sometimes it’s useful to stash all the changes and start with the tests. That’s a very good sign you’ve lost your way, and you can reflect later on whether it’s a pattern or just a bad day.

Pain is information. If you make use of the information then it redeems itself. If you don’t then it’s just needless suffering.

If you're working with a big ball of mud, I find that the best approach is to immediately start doing TDD with hermetic end to end tests.

Hermetic = could run just fine on their own if run on a freshly installed OS that is cut off from the internet.

The first tests you build this way will be extraordinarily expensive (faking databases & http calls is fiddly), but they pay enormous dividends.

Once you have a large enough body of these and youve refactored some clean interfaces underneath, you can start writing future tests against those.

I'm firmly in the camp that you shouldn't mock the DB and have a local instance for testing but for external resources that you can't reproduce locally I think that's fine.

Otherwise I agree with you.

By faking the DB I meant either running a local, prefilled fake DB server for every test or faking the interface to the DB.

Which one you should do depends on how complex your interactions with the DB are.

Some apps (e.g. CRUD) have half of their business logic encoded in DB queries in which case faking the calls is a bad idea.

Others only do, like, 2 simple queries. In this case there's no point running an actual database outside of a couple of E2E tests.

Yup then I'm with you