After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you're writing can be tested. I don't see writing the test first as a must, only good to have, but testable code is definitely a must.

This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don't have to enforce my preference on anyone. I'm not restricting the team. I'm not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.

Just think how you plan to test it, anyone can do that.

I had a coworker who was big into TDD. He was using it on a disaster project that was way over budget and long overdue. I was sitting in on a meeting between him and the client when he tried to defend the project's status by saying "you don't understand - we've written six times as much test code as actual code!" The client almost punched him.

IMO it doesn't matter what methodology you use if a) you don't have the ability to understand what the client actually needs, and 2) you can't code your way out of a paper bag (or to put it more technically, if you over-architect your solution and then can't solve all the self-inflicted problems you run into).

This reminds me when a senior engineer asked me to write exception handling on a one-off python script, not a production code - just a script devs can use internally. The "handling" was that the program should exit when a file is not found. He wanted me to try the file open, except the file error, print "file not found" message and exit(1).

Guess what, genius. Python already does that for you. No need to write an extra wrapper needlessly.

I much prefer having an in-memory database than mock what a database does.

Which sounds great in theory but then you get to find where your prod DB and testing DB differ and you have to keep chasing that. Unless you are using something like SQLite which has both (disk and in-memory) as an option.

I worked at a place that used a different in-memory DB (H2, IIRC) in place of our MySQL DB for testing. It ended up being hell to maintain and had to have hacks for how H2 and MySQL differ (tests would work in H2 but fail if run against MySQL or vice versa).

Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc.

Oh good grief. I haven't even heard of half of those, and I've been writing code longer than most interviewers.

Also doing it with dependency injection and all that.

After struggling with several DI frameworks, I've come to the conclusion that DI is far too opaque and unpredictable to be useful.

OOP is also intentionally opaque, mind you, but debuggers can see through it if necessary, so that's fine. DI, on the other hand, is opaque even to debuggers!

I much prefer having an in-memory database than mock what a database does.

I much prefer using the same DBMS for tests as the one used in production. That way, I can use its special features (like arrays as query parameters), and avoid bugs resulting from differences between DBMSes (which would only appear in production).

You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.

Indeed, and you usually can. Even if your system involves a bunch of services that normally run on different machines, who says you can't spin up instances of them as part of the test? Tests are arbitrary code and can do anything that any other program can do, including starting subprocesses. Just be sure to terminate them once the test is finished, even if it fails.

I like to mock up dependencies with Docker Compose, then run all the tests against that. Keep the compose file in the repo, of course. I don’t tend to build a lot of real unit tests unless I’m doing something very novel and self contained. When you’re just assembling a service out of REST libraries and databases, integration testing is mostly what you want.