Comment by spoils19
3 years ago
That's awesome to hear! I myself do something similar with my own code, but then again, I also trust myself more than any computer ;)
About how long would you say that process takes you? Do you repeat it every time a minor change needs to happen to your code? If not, how do you verify the impact of your changes?
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.
[edit] just a note to any new coders reading this: Spend the time to always read, read, read everything about how to harden the code you write for security purposes. 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.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.
1 reply →
> 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.
1 reply →