I'm a devOps engineer - I wrote the provisioning system for my company's cloud efforts with AWS. I'm a ruby programmer, and ever since I started in industry I've been 'the programmer' on the team (with a bunch of Systems Admins). For my whole career I've been feeling a lot of guilt about not using any tests - I just code a solution and iterate until it's working. Last month things settled down enough so that I could devote an entire week to writing tests in minitest for my provisioning system. I was very inspired to responding to every change request with 'red-green-refactor' but after a few weeks I stopped. it's hard to do it alone, and easy to slip back into my old ways of code and fix. Just singin the blues.
If your code mostly does API calls to provision/teardown resources maybe what you should look into are 1) integration tests or 2) unit tests where those calls are mocked.
Don't give up. It gets easier with time and practice. Eventually you reach a stage where you wonder how you developed anything without TDD. My coworkers are complaining about how long our build-deploy-test cycle is, and I was kind of perplexed. I write my tests to run outside of the environment, so I only have to go through those long cycles a few times because my test cases have caught most of the bugs already.
Tech Industry
Yesterday
5188
Google doing more layoffs, restructuring including country moves
2024 Tax
Yesterday
2564
Biden’s new tax proposal is wild
Tech Industry
Yesterday
2734
Go woke, go broke: Google fires 28 employees involved in pro-Hamas protest
2024 Presidential Election
Yesterday
1439
Biden ruined America and tech! Tax plans are insane
Tech Industry
Yesterday
342
Chances of meta clearing E5 with screwing up one coding one round and acing all other
Try splitting the code into smaller modules, this way you have isolated tests and less coupling. That will also alllow you to gradually add tests as time allows and to pause the TDD approach as you see fit.