Well, test your code but don't say it is production ready after testing it. If a formal unit testing procedure is not in place for the project, at the very least, another human needs to test your code. This other person doing the testing doesn't even need to be a developer (if the code is fronted by a GUI).
You can spend hours on end testing your own code and find nothing wrong with it. Pass it off to the developer next to you and he is able to break it in under ten minutes. I obviously don't quite understand the psychological underpinnings of why these biases occur when testing your own code, I just know that they do. Perhaps it is a matter of motivation. Put yourself in role of tester. Someone gives you some code and says "here, break this". Whereas testing your own code may result in more work on your part. Maybe it is easier to fix things that need to be fixed as opposed to if I don't see it, its not broken.
I've actually thought about this while testing my own code and thought about previous testing sessions. I recalled scenarios where I figured good enough==not broken. I'm sure anyone can think of these mishaps if they try hard enough. The good news is that it is unavoidable. Try all you want, you alone will not eliminate your own bugs. Let someone else test your code.
No comments :
Post a Comment