Rough answer, I spend about 50% of my time just thinking about pitfalls before I actually write the code, 10% of the time writing it, and the other 40% testing it to my satisfaction (doing every stupid thing I can think of someone doing to break it) before I deploy.

Usually though, in practice, this looks like tracing/logging several times in the middle of each function to make sure I'm getting it right. Where unit tests are supposedly most handy is when unexpected types are passed to functions, leading to unexpected errors. The majority of proofing against that can be done by strict typing and good code documentation.

Ultimately the best test is when you ask yourself "wait, what if someone sent this" and you try it to see if you can break your own code. That's just a spidey sense in the back of your head. If you didn't have the specific doubt to begin with, I don't know how you could write a unit test to disprove it anyway.

i.e. you're the only one who can update your code because only you know what it's precisely supposed to be doing. Also if you come back in a year you'd better be able to remember everything.

I am sorry if I am being a bit mean - I just have had to take over maintenance of things like this and have found it a nightmare from hell so far.

I think code comments and breaking everything into well-named functions, along with ample side documentation, make it fairly clear to follow. The business logic gets confusing - but anyone who had to work on the code would need to understand that first anyway. I don't think the code itself is difficult. It's all in the docs. Frankly, I don't always remember how something should work and I need to spend a few hours to re-understand some tricky piece of 10 year old code again before I change it. That's the job.

My main concern, of course, is not leaving a mess for myself. That should be every coder's priority. Then taking over someone else's projects wouldn't be so hard.

The problem with anything you've been doing for 25 years is there's not that much chance that I, or anyone else, will convince you to do it differently. That is true of me too of course.

Nevertheless, I highly recommend having automated tests and running them in the presence of memory profilers etc like valgrind if you're using a compiled memory unsafe language like C or C++.

I would look for another job if I had to work with someone that refused to write them to be honest. It's not that I love tests, but I have had to fix other people's bugs.

> Ultimately the best test is when you ask yourself "wait, what if someone sent this" and you try it to see if you can break your own code. That's just a spidey sense in the back of your head. If you didn't have the specific doubt to begin with, I don't know how you could write a unit test to disprove it anyway.

I can't speak for others but that's precisely how and why I write tests. It goes like "Wait, what if someone sent this" -> check what happens -> write a test to automate that check -> optionally, fix the code to handle this specific case.

Then, over time you accumulate tests that check all these weird edge cases for you and it doesn't take much to run them over and over again every time you change the code.

noduerme already addresses this.

> Unit testing will not save you from SQL injection or XSS attacks, so study those and bulletproof your work against them first before you worry about mathematical proof that your database call never results in an error under some odd condition.

I understood both this quote and the one I quoted above as OP arguing that automated testing will not save one from thinking about and fixing possible edge cases therefore automated testing has no value.

I agree with the first part but not the conclusion. My point is that with both manual and automated testing, you still needs to think. It's just that automated tests let you build an executable knowledge base of all the edge cases, errors, security issues etc. you've thought about in the past, and run them with every code change. Hence the value.