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.
Product Management Career
3h
277
TikTok Internal Situation. Should I join with huge bump in compensation?
Tech Industry
10h
2624
Avoid teams with only Chinese or Indians especially with a Chinese/Indian manager
Tech Industry
Yesterday
34208
Worried that our top performer is an attrition risk. How do managers handle this?
AMA
Yesterday
3461
I’m a professional coaster AMA
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.