My rule is simple: if I want to test something, I have to code it. I don't know if it's full TDD, but if it's worth testing it's worth automating. If there's

My rule is simple: if I want to test something, I have to code it. I don't know if it's full TDD, but if it's worth testing it's worth automating. If there's some edge case where I trust the logic to Just Work, I don't test it at all. The important thing I find that helps with the mental overhead of testing is a long script of integration tests is better than nothing. Too often "TDD" is interpreted as creating perfect isolation of unit tests on each method -- which is fantastic! But is also a lot of work. Worse is better. If just checking in some precondition data and loading it in and then sequentially running a script of automated tests that all have side-effects that could impact the next test is your MVP for a test framework, do that! Having a suite that you have to run fully end-to-end isn't great, but it's better than nothing. When that frustrates you, refactor it into true isolated unit test.