Tag Archives: testing

Don’t forget the basics

There was something I was asked to troubleshoot between two different environments. Most reputable places will give at least 2 different environments for application development, the best is to have at least three, development, stage, and production areas. I was asked resolve and fix an issue in the stage area, but it was not happening in the development area. Normally, I follow a few simple rules to get through this type of troubleshooting. Today, for some reason, I blew those off. Now this is not an end all be all type of list, and I use what is good for me and what I have learned. Other people may find different ways to do this, and find ways that work for them more. Here are some of the major items I check for with web applications in PHP.

  • Check the Apache services, connection, or anything that would lead to just no resulting page whatsoever.
  • Check the DB server, make sure the server is working, the connection is good, the data flow is there
  • Check the permission of the database, the tables, the sequences, etc. Whatever is needed from the database, make sure the caller has permissions to do that task
  • Check the code objects/PEAR packages/framework extensions are installed. If you have a recent version of PHP, then you should be good for PEAR, and if you have the most recent framework version (like Symfony, CakePHP or Zend) that should house them all, but never hurts to check
  • Check instantiated objects, function calls, object variables, etc. Most of the time it could be a spelling error, or the call is made before the object is created
  • I check the data being returned and the statements making the calls. What I am calling for may not be listed, or I may need to grab data from another table. This sometimes creates errors for other functions expecting an array and getting a character value.
  • Dump the session, maybe the session variable was never set, or never started.
  • Form data and POST variables are always good to give a good ol’ var_dump() or print_r().

Obviously this is not all of them, nor is this just a quick checklist. Some of these may take a while to go through, and may have a lot of details to peruse through to find the answer. This will not always give the answer the quickest ways, nor will it ever just shine the answer down to you. But it helps to isolate issues starting form the global level, work down to the application level, and then down to the code level. Plus, it helps eliminate the obvious problems first, so that when someone asks “is the printer is turned on?”, I don’t sit there looking stupid because “it is turned off” and I just never looked. But that is what happens at times.

Today, I completely forgot about permissions on a database. Sure, the code works in development, I have my hands all over that environment. But when it does not work in the staging area, I should have checked permissions instead of just lopping off my hand with endless queries to try and see where the code went wrong. Just one simple act of a GRANT permission to the application user calling the query would have fixed it. But I was forgetful and should have checked that first. Sometimes developers go down the wrong path. To stay down the wrong path, well, you can finish that one on your own.