I am not a programmer. And I am by far not good enough in any language to spontaneously think architectural enough to create unit tests and do TDD. I always fe

I am not a programmer. And I am by far not good enough in any language to spontaneously think architectural enough to create unit tests and do TDD. I always feel like I should be doing more tests. That this is the correct way to do things. Being a data/web analyst I have to say that I once created extensive tests for a specific part of custom javascript logic setup by a former agency of my client in the tag management solution they used. I even had to mock basic functionality from the tag manager (Adobe Launch) to make it work locally. When I took over it was a mess of code that mapped url parameters to their specific marketing channel logic (you could have done this purely in Adobe Analytics, though - but I was never able to find a way to explain the unnecessary complexity of the implemented solution). In the end I had created around 60 test cases to ensure this fragile bit was in a way that enabled refactoring. It worked. Especially when around one year later, a colleague of mine who had taken over the client needed to change stuff in there, had it break and asked me. I thought his solution should work, but the tests told a different story. Within half an hour we had it nailed down, fixed and running flawlessly. If I ever have such a complex piece of logic anywhere I will surely learn how to write tests in the respective language of choice. Until then I will happily fatfingered stuff on my own amateur projects, though.