This week has mercifully come to an end, and not a minute too soon! I'm not going to say it was a terrible week, because it really wasn't. It was just a bit more chaotic than even I like. And I like me some chaos!
Even through the chaos, I was able to wrap up a couple projects and found time this evening to take my daughter out to the movies. Although, the people dying in the Hunger Games did make her sad, so I'm not sure it was exactly a win. I may have to examine that more in a future post.
Yeah, WordCamp Presentations
When we were going through the large list of WordCamp presentation proposals, I selfishly picked out one that was of interest to me. Ben Lobaugh‘s submission about getting started with unit testing. I talked with some guys on my team about the submission and the general consensus was that we've all seen talks about unit testing before, but none really start at the beginning. When I reached out to Ben to tell him he was selected, I made it clear that we wanted to see actionable ‘getting started' examples. He agreed, so you aren't going to want to miss his talk.
Unit Testing, for those unfamiliar, is a process where you set up a series of tests for your code. If you have a function that runs a calculation and is supposed to spit out a number between 1 and 5, for example, you could write a test to run that query and check the results. If the value comes back as 27, the unit test would fail and give you a warning that something is wrong. Having unit tests for your code can save you a ton of time when trying to track down an errant function.
Well, it works on my machine!
As I mentioned in yesterday's post, I had a project go off the rails yesterday and it made for a pretty long and grueling day cleaning up the mess. When we finally called it a night, we knew there were still a couple things that were going to have to be followed up on in the morning. So when I got to my desk, I dove right back in head first. There was an issue with the menus on two archive pages. They just weren't showing up. Every other page worked just fine. But not these two. Well, let me clarify, on the client's dev and live environments they weren't working. However, on my local machine and on my development server, it worked perfectly. So clearly, the issue wasn't with the code, it had to be an environment thing, right?
Midway through the day I had tried most everything I could think to solve this issue. Nothing was working. Nothing. It HAD to be their server. I hopped on a call with one of my devs just to walk him trough what I was seeing in the hopes that he'd have some insight. I send him the link to the page in question, he clicks the link and reports back, “The page is working fine for me.” Blank. Stare.
I asked him to view the source code to look for a hint I left in the code. The hint looked different for him than it did for me. This was finally my first real clue as to what was could be going on. I dug back in and was able to cross a couple other items off the ‘possible reasons' checklist. But still, the pages were broken. I called up another one of my devs, showed him the issue, and within about 15 minutes we not only found the issue, but had it solved, too. We submitted the code, got it to the client's server and we were finally able to put that issue to rest.
What went wrong?
After something like this happens, I try to figure out what happened and how to avoid it in the future. Once we solved the issue, the “what happened” part became obvious. A feature request at the 11th hour that we hurried to get in place did not have ample testing performed. A small difference between our environment and the client's environment masked the issue from us until it was too late.
Since this project has a central function that gets used throughout many different sections of the site, it's imperative that it's returning the proper value. If not, well, it may just cause menus to decide not to display. Or, it may manifest itself in other less obvious ways. If this had been a site for a bank and that function was miscalculating somebody's interest rates, the mistake could have taken way longer to find and had far worse repercussions. But, if we had unit tests in place for this project, I would have spotted the issue in a matter of minutes.
I have 2 or 3 projects that are large enough that they should have unit testing on their code. So, Ben, no pressure, but I'm looking to you to show me the way at WordCamp Vegas.
Leave a Comment