Double Check

Some lessons are learned the hard way.  Fortunately, some are only learned the almost-hard way.  This is a story about the latter.

I was working on a user profile feature.  A neat little slide out div that allows a logged in user to edit their name and email, and reset their password.  As with most web development projects, it was a bit of an iceberg.  Creating the slider and simple form was fairly easy, but also on the list of necessary items was: Javascript validation and visual feedback, PHP processing of submitted info on the server side and server side validation of that info, and SQL statements for updating the database.  The last two are where I made my almost-hard lesson.

On a couple different recent projects, we’ve used a nice ORM system.  Short for object relational mapping, an ORM basically prevents you from ever having to write SQL directly.  Django uses one- you just create classes in your models.py file to ‘model’ your data.  .NET also does (I think)- add a new .cs file to your models folder and you can create the table with get and set methods, type tagging, etc.  Those frameworks will then produce the SQL commands (specific to the type of database you’re using) and you’re good to go.

But on this project, it’s an older setup – just a simple PHP/MYSQL system.  I’m generally ok writing SQL, but when you get out of practice, you make stupid mistakes.  I grabbed the right table, used an UPDATE command on the row denoted by the client id, and tested.  What was missing?  Well, in this system, there are two important keys for users: the client_id (basically a group- one client can have many users) and the user_id (which is the actual unique id for a specific user).  By only grabbing the client id, I’d created a method to update all users related to a client at once (not exactly a useful function).

I tested the update and saw my user’s profile save the correct info- great!  But then I checked the rest of the users for that test client- they were all named ‘Testy Guy’ and had email ‘test@test.com’.  After a few moments of panic, I realized that my mistake, while really stupid and dangerous, was not as bad as I’d thought.  It had only updated users for that one test client (I had, after all, grabbed the client_id) and I was still working in a full test environment (testing only database and code base).

So, an almost-bad mistake.  Still, a really careless mistake.  But a reminder and good lesson to always check my work.  In this case, adding an important client side check:

  • Checking that the unique username is not null or a blank string when submitting (this will ensure that the server code gets all the info it needs)

And an even more important couple server side checks:

  • Check that username again, return false with an error if blank
  • And use the mysqli_num_rows function to ensure only one row (and therefore, user) is being updated.  If that function gets more or less than one, return false with an error.

And it renewed my interest in getting into automated testing.  I know- I’m a monster for not doing this sooner, but it hasn’t been pushed at any job I’ve worked so far.  And it’s not really a popular course/tutorial topic.  There’s a rush (I know I’ve felt it) to get something working and up on the screen- but the more I read about (and experiment with) truly testing code, the more I realize that it will pay off in the long run.  More on that next week!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s