I have been programing in java full time for a year now and one thing i keep finding is I have having a hard time finding some really easy to spot mistakes. Currently in my process I will get a request, Layout what needs to be done, create the SQL code (When I am writing to read from our database) and verify it, Create the GUI, then I will test the program and modify code several times. Then I get what I believe to be the final result and send it out. A week or two later some one comes to me and ask why X is not working. I take a look and it was over something really dumb like I put in a 7 instead of a 2. Or I referenced the wrong variable.
So my question is what do you guys do to avoid these small mistakes from hitting production?
Guiding the development of your application with automated unit tests and integration tests is a good way to build confidence for you and your customers. Writing your requirements as automated and repeatable tests is a great technique to bake in confidence that your application behaves as intended.
Additionally, involving your user(s) early and often so that you can draw up automated acceptance tests can also help tremendously. A comprehensive set of tests starting from unit tests, to integration tests, to user acceptance tests, load/performance tests, penetration/security tests, all preferably automated plus some manual exploratory testing, can really go a long way in providing the kind of timely feedback that you need to make adjustments to your program before you go to production. Many programmers call themselves (or have the title of) software engineers but most self-respecting and qualified professionals in any other field of engineering will push products out into the world only after first putting it through a battery of tests to make sure it is ready; we who call ourselves software engineers should do the same.
Thank you both for the suggestion. I have been doing research on it and trying to figure out the best way to apply it to my issue but it is just not clicking. Is there a particular resource you would suggest learning from?
There's not one single resource that I formed my habits of testing from. I've picked up things along the way from one book or another. Refactoring by Martin Fowler, OO Analysis and Design by Craig Larman, Design Principles by Robert "Uncle Bob" Martin, Four Rules of Simple Design by Corey Haines based on work by Kent Beck, ... the list goes on and on. Those authors will cite other books or each other, so you go back and read those, then you end up coming full circle and reading the same passages again and gain more insight, go back and practice some more, read the things again and gain more insight, practice again, ... and so on and so forth. It's a never-ending cycle of reading, practice, gaining insights. Central to all this, of course, is the mindful practice you have to do.
Practicing really does help. Just like athletes who get more reps in during practice, the more reps you get in by just writing small programs while focusing on fundamentals and principles, the easier it gets to actually do it on the job. But keep in mind what every music teacher ever has said at one time or another: "Practice only makes habit. Only perfect practice makes perfect." So practice doing the right things and you'll end up with the habit of (almost always) doing things right. And when you do mess up, your mistakes are easier to find and easier to fix.
One final note: If you're wondering what all those books have to do with testing, it's because I practice what's called Test-Driven Development. Central to that practice is design thinking, and simplicity, and expressiveness, and quality. Testing is only a means to these ends and it's what drives you to think about your design, about quality, about simplicity. So yes, these are all related to testing, or rather, testing is related to all of these because the goal is not having tests; the goal is writing good code that's correct and easy to read and maintain.