Category: Development

How long is too long (for unit test method names)?

January 12th, 2011 — 3:44pm

As I ws working on some new development in our codebase this morning, I started updating some
unit tests to match. I was looking through the code for one of them and came across a test name that was easily 50 characters long and
it got me wondering – what was the popular opinion on naming conventions and commenting in unit tests. Obviously, there’s some things
(like annotations) that have to be in comments, but do you sacrifice clarity of a comment for a method name that you can basically read
like a novel?

I mentioned something on Twitter about it and here’s some of the responses I got:


Rafael Dohms (rdohms)
@enygma @elazar @bdeshong taking into consideration PHPUnit and its use of method names (like testdox) i would focus more on name not doc
2 hours ago

weierophinney (weierophinney)
@enygma I don’t document my tests; the test name and test content *are* documentation. /cc @elazar @bdeshong
2 hours ago

weierophinney (weierophinney)
@enygma I do those all the time. For use with #PHPUnit’s testdox output. :)
2 hours ago

Ralph Schindler (ralphschindler)
@bdeshong @elazar @enygma if you are using PHPUnit, run the tests with –testdox, you’ll see the benefit of long test names :)
2 hours ago

Chris Cornutt (enygma)
@mwillbanks ah, good point…I can see how that’d be handy heh

Mike Willbanks (mwillbanks)
@enygma putting it in a docblock is nice, however, when running it on a CI server it is nice to see what broke by method name and test name
2 hours ago

Mike Willbanks (mwillbanks)
@enygma I think we have one that is almost 100 characters :) here is 1 example: testEditActionRedirectWhenJournalEntryNotFound
2 hours ago

Brian DeShong (bdeshong)
@enygma @elazar 120 characters? :)
2 hours ago

Michael Maclean (mgdm)
@enygma around the 100 character mark? :)

2 hours ago

Chris Cornutt (enygma)
@elazar @bdeshong ah, but where should method names end and docblocks begin? ;)

Brian DeShong (bdeshong)
@enygma If the method name is long, but descriptive, then that’s good. Descriptive test method names are better than short ones.
2 hours ago

Matthew Turland (elazar)
@enygma Better to be verbose and accurately descriptive than overly concise and obscure? :P
2 hours ago

jcarouth (jcarouth)
@enygma Hey, I’ll take that over testApp1() and testApp2() any day.
3 hours ago

Chris Cornutt (enygma)
well hello entirelyTooLongUnitTestMethodName, nice to meet you
3 hours ago


That last one was my not-so-innocent comment that started the whole thing off. I’m still interested, though, in what developers
out there think is a good point to switch from documenting via the test functions name and moving it up to a docblock comment. Seems
like there’s arguments for both sides and I’m not sure if there’s a “winner”, but it’s always fun to get opinions.

What are your preferences in unit test naming versus commenting?

10 comments » | Development, PHP, Testing

Using Models in Fuel

December 23rd, 2010 — 3:31pm

In my previous post on using the Fuel framework I looked at the basics behind getting a site up and running. This time I want to take it a step further and tell you a bit about my experiences getting a Fuel application to talk to a database (in my case MySQL). To learn the process, I fell back on one of my standby sites that’s been rewritten in a few different frameworks now including Solar and a really, really old version of the Zend Framework. It’s not an overly complex site, but the version is starting to show its age. So, I usually take that as an opportunity to rewrite the site in something different, just for the experience.

I’ve already started on a version with the latest download of Fuel and, as a part of it, explored the database model connectivity feature. Now, all of this code is generated from me just looking at the source (since there’s no docs to speak of *cough*) so there’s probably a better way to do some of this that I don’t know. So, lets get started with a basic model.

In my database, I have a few tables – two of them are the “news” and “news_tags” tables. The relationship between the two is news.ID -> news_tags.news_id. Thankfully it works out that this is the default mapping for the relationships between the models. More on that later though…here’s my sample SQL:

create table news (
     news_title VARCHAR(200),
     news_story TEXT,
     date_posted INT,
create table news_tags (
     news_id INT,
     tag_name VARCHAR(50),

Let’s start with the model files – one for each of the tables. Here’s the basic structure of the file:

namespace FuelAppModel;
use ActiveRecord;

class News extends ActiveRecord/Model 
     // define a sample method
     public function getLatestNews()
          $results = $this->find('all',array(
               'select'        => array('news_title','news_story','date_posted','ID'),
               'limit'         => 10,
               'order'         => array('date_posted','desc')
          return $results;

This is enough for Fuel to now know about the “news” database table. Obviously, you’ll need to have the database connection information correct in your db.php to connect to your instance. A few things to note here – the namespace loads in the base Model functionality so the News class can extend the ActiveRecord bits it needs. The ActiveRecord functionality is contained in a package in the standard Fuel download.

In this model, I’ve defined a simple function to pull out the latest news from our “news” database table. This uses the “find()” method that comes with the ActiveRecord stuff. That first parameter can be one of a few things.

  • An ID number of the record you’re looking for
  • The string “all” to return all matching rows from the where
  • The string “first” that essentially puts a “limit 1″ on the end of the statement

The second parameter sets up the rest of the SQL statement – the “select” array lists the columns to fetch, the “limit” restricts the results and the “order” allows you organize the results by a column. There’s also “offset” and “where” that can help get it more specific. The results are then returned back from the method. If you’re more in the “heavy controller” camp and want to do more complex stuff in there, you can also make a model object inside your controller:

namespace FuelAppController;

class News extends BaseController
     public function action_index()
          $News = new FuelAppModelNews;
          $results = $News->find('all',array(
               'select'        => array('news_title','news_story','date_posted','ID'),
               'limit'         => 10,
               'order'         => array('date_posted','desc')

This essentially does the same thing. Now, lets talk about conventions for models here. If your table name is one word, it’s simple enough – for the “news” table, the model’s name is “News” and the file in /classes/models is “news.php”. For something a bit more complex like “news_tags”, you name the file “newstag.php” and the class “NewsTag”. Note that it looks for the singular version of things – “NewsTag” even though the table is “news_tags”.

Simple, right? Well, if all you need to do is make basic queries and pull that data back out, you’re all set. You can stop here. If, however, you need something a bit more complex like say, table relationships, keep reading. Sure, you can manually join all of your data together, making multiple queries and looping through endless loops to match things up. If you want to save some time you can use the table relationships build into Fuel to do the work for you. There’s currently three different kinds – belongs to, has many, and has one. For the sake of example, I’m only going to show you a “has many” example on our “news” to “news_tags” tables.

Setting up the relationship is super simple. In our News model, we’re going to set a new class property to tell the framework about the relationship:

namespace FuelAppController

class News extends BaseController
     public $has_many = array('news_tags');

     public function getNewsDetail($newsId)
          $results = $this->find($newsId,array('include'=>array('news_tags')));
          return $results;

Don’t look at the “find()” call yet, lets concentrate on the new property. This “$has_many” property lets us define the table names we want relations to. By default Fuel tries to look at the other table for a column matching the [current table]_id pattern. Thankfully, we have one of those: the “news” table’s ID relates to “news_tags.news_id”. Works like magic! Additionally you can also define other parameters to manually specify things like the column name to map to.

Okay, let’s look at that find now…we have our relationship defined to the other table, but Fuel knows we might not always want to include that data on every call. To let it know when to pull the news_tags data in, you have to specify it in the “include” parameter of the find() options. When the query runs and the data’s returned, you’ll have the news_tags data in $results->news_tags for your consumption.

There’s one slightly tricky thing that I came across when working with the model features. When it tries to do the join, it looks at the name of the model class it’s trying to use and pulls the name from there. In our case “NewsTag” isn’t the right name for the table. You can however define the table’s name in the $table_name property of the model, but that didn’t seem to cooperate either. It looks like the fault lies in this chunk of code in the “hasmany.php” extension of the ActiveRecord component, around line 212:

$dest_table = AppInflector::tableize($this->dest_class);
$source_table = AppInflector::tableize($this->source_class);
$source_inst = new $this->source_class;
$dest_inst = new $this->dest_class;
$columns = $dest_inst->get_columns();

In the above snippet it tries to run the “tableize” inflector on the model class’ name to pull out the table. In our case, though, the names don’t match and unfortunately the join() method doesn’t seem to care about the $table_name value and just keeps going on its merry way. It’s a pretty simple fix, thankfully:

$dest_table = (isset($dest_inst->table_name)) ? $dest_inst->table_name : $dest_table;

With this defined, you can tell it that “$table_name = ‘news_tags’;” and it’ll respect it.

For those used to the more object oriented method of models, there’s also the usual CRUD methods you can use to manipulate the objects:

  • save()
  • update()
  • destroy()
  • and, of course, the find() call

I hope this was helpful and like I said, I’m sure there’s a few things that I didn’t get quite right just because I was fishing through the source to figure them out. I’ve been working on some simple templating for the site, so maybe I’ll write up a post on that next. As always, please point out my mistakes :) That’s the only way to learn!

4 comments » | Development, framework, PHP

One ToDo list to rule them all?

November 16th, 2010 — 3:32pm

Okay, so _ I’m going to put this out there so I can get some feedback. I’m looking for a good To Do list manager with a few criteria:

  • I’d love for it to have desktop software that would sync with the site (or some other resource) and allow me offline access to the lists
  • It needs to be able to prioritize items
  • It should definitely allow main and sub-categories (one level of categories? that’s crazy talk)
  • The desktop software would need to be cross-platform (pc & mac) – maybe an AIR client?
  • Bonus points if it allows sharing between users or just public access to the lists (RSS?)
  • Mobile support is cool, but not required

I like the simplicity of some of the tools out there, but none of them seem to meet what I’m looking for. Is there anyone out there that’s come across something like this? It’s driving me nuts that there’s not one that’ll fit my needs.

3 comments » | Development, Personal, Web

A Partial Review of “Test-Driven JavaScript Development”

November 1st, 2010 — 2:21pm

So ever since the fine folks at Addison Wesley sent over a copy of Test-Driven JavaScript Development (by Christian Johansen) I’ve been trying to wrap my head around a new sort of testing when it comes to web apps. I’m not even half-way through the book and I’ve already had my mind blown by advanced javascript and testing methods that I just never thought about when I work on my frontends.

I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.

He starts with an introduction to TDD and a general how-it-works with javascript quickly followed by an introduction to his tool of choice – JsTestDriver. All of the test examples in the following chapters are run with this tool. Thankfully it’s simple to set up and even easier to write tests for. He shows some introductory tests to help you get familiar with things before diving into the next section – testing javascript itself.

I have to admit, this section left me at a loss for words. I thought I knew a good bit about how javascript works, both out in front and behind the scenes. I was surprised, however, just how much of the functionality he tested I had no idea worked that way. It’s pretty in-depth, so if you’re a beginning javascript dev, you might go read some more tutorials before diving right in.

I’m just now getting to the “Unobtrusive Javascript” part of the book (Part 2, Chapter 9) so I still have a ways to go, but each page is enlightening, especially for some one like myself that’s has a primary focus on backend work and unit testing. I’d definitely recommend this book to anyone looking to get into testing their frontends – it’s a great resource and can probably teach you a thing or two.

I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.

3 comments » | Book Review, Development, javascript, PHP, Testing

Are You an Olympic Developer?

February 14th, 2010 — 12:31am

The Olympics have just started and I can’t help but look at those competing and liken them to the development work so many of us do. What’s the same, you ask? How could an international sporting event of the best of the best possibly connect with the work we do behind our keyboards? It’s simple – it’s all about being the best.

Olympians work most of their lives (if not all of them) trying to become the best at their sport that they can be. Some of the figure skaters have even been paired since they were little kids and know each other’s moves as if they were their own. They have honed their craft down to the point where they know in the first thirty seconds of a routine or race how well it’ll turn out in the end. They know the result because they know themselves. They’ve worked hard to get to where they’re at and they know that to compete on this new level, they’ll have to step things up and do even more than their best.

It’s easy to see how this relates to us, the software developers (or managers of these developers) all over the world. There’s no excuse for you to not look at things on a more global scale and try to be the best you can possibly be. Sitting in your chair and being comfortable in the knowledge you learned five years ago isn’t enough. Don’t lull yourself into thinking that, just because you know your current codebase, you’ve done all you can. Get out there, look at what other developers are doing and hone those skills. There’s tricks that you can learn from the best and tools that you can use to hone your own development work into a razor sharp edge that can cut through any problem and push you up into that next level of development.

Who knows…you might just find something you can apply that could make you and your development soar to new heights and help you feel the rush that you did when you were first learning a language – flying headfirst into the unknown, unsure about what was to come and where you might land.

Don’t be afraid. Take the risks. Become the best you can be.

5 comments » | Development, PHP

Adventures in Git (Merging)

January 8th, 2010 — 3:21pm

Starting out with a new version control system is always a unique experience. Half of your time is spent crossing fingers and hoping that you didn’t just cause irreparable damage to your repository and the other half is time spent pouring over manuals and Google results to try and get just the right commands so that the worst case (hopefully) never happens.

For a little bit now, I’ve been playing with git (due to my pet project, being moved and open sourced over on github. It’s a different sort of experience than I’m used to coming from a CVS and SVN world where there’s one server and everything you do goes through that. Git’s different in its distributed nature and it takes a bit of getting used to – some of the core concepts are a bit different since, essentially, your clone is a full copy of the repository (and is a repository all to itself). It’s a little strange and I don’t think I fully have a handle on it yet, but I’m getting (gitting? yeah, had to throw in a pun somewhere) there.

In the meantime, I came up against something today I hadn’t had to deal with on the project. Previously, the source was on a SVN server hosted on another machine. I had some other developers working with me on it while I was over there, and most of the changes were pretty easy to integrate with few conflicts. I’ve gotten used to handling merges in SVN, but since git’s “total repo” method is a good bit different than SVN’s approach, it took a little doing to figure out how to merge in changes from a forked repository on github and integrate them back into the master. I (finally) got it to cooperate so I wanted to share the steps I took to get it working. I know this isn’t the only way to make the merge happen, and probably isn’t even a true merge, but it got the job done.

In this example I’m going to be merging changes from Lorna Mitchell’s fork of the code back into the main line.

First off, for the impatient folks in the front row, here’s the full list of commands:

mkdir lorna
cd lorna
git init
git remote add lorna git://
git remote add joindin
git pull joindin master
git checkout -b lorna/master
git pull lorna master
git add path/to/file.php
git checkout master
git status
git commit -m'Merging in the changes from the fork'
git push --dry-run --repo=joindin
git push --repo=joindin

Want a bit more? Alright – here’s the explanation for the steps above:

  • Start with an empty directory: You don’t have to do this, but it made me a bit more comfortable to keep things out of my working copy.
  • Go into the directory and make it git-controlled with the “git init”
  • Set up some aliases: This just makes things easier to refer to down the line. In this case we’re setting up aliases for the “joindin” and “lorna” repositories to point to the remote sources on github
  • Get the main line of code: Do a pull to get the master line of code from the joindin source
  • Create a branch: When you use the “checkout” command for git, you’re moving between branches. In this case, the “-b” flag tells it to make the branch too since it doesn’t exist. Our new “lorna/master” branch is created.
  • Pull in Lorna’s code: With the new branch in place, we can pull down the fork’s code and push it into the branch (the master line from her fork). This is where the fun starts. If you have conflicts that pop up, this is where you’ll see them. They’re easy to fix, though – the technique’s similar to other version control systems and you basically just delete what’s wrong.
  • Add the fixed files: There wasn’t a “resolved” command like SVN has that I could see. The only thing I saw was to “add” the files back into the commit once they’re ready to go.
  • Switch back to the master: Move back over to the master branch (of the “joindin” repo) by doing a checkout on it
  • Check your status: Use the “git status” command to see what’s going on and if there’s anything else that might need to be done before the commit.
  • Commit!: You’re ready to commit the changes to the master branch. Issue the commit and fire away. Remember, this is all local until you do the push, so if something freaks out, you can always start over.
  • Now push!: If all went well, you’re going to end up with an integrated version of your repository and you’ll be ready to push. The “git push” command also has a –dry-run option use can use if you want to check before you make the leap. The –repo option is used to defne which repo you want it applied to.

So there you go – it’s a little tricky, but not too bad once you know the steps. This was just a simple merge, so I know there’s more to it in the future, but I suppose I’ll work on that when I get there. Hopefully this helps someone out there!

3 comments » | Development, git, PHP

Is it a Developer’s Responsibility?

December 1st, 2009 — 9:35am

Last night, several of us were treated to a dinner as a part of this year’s Microsoft Web Developer Summit (great dinner, by the way – Anthony’s in Kirkland, WA). Seems like there was just about a one-to-one ratio at one point of MS employees to PHP developers attending. It was interesting to see how this played out in conversations and in the general flow of the evening.

At the table I was sitting at there was a MS rep from the Windows team, Ani, who was pleasant, engaging and genuinely seemed interested in what “this PHP thing” was all about. Some of her questions could have been answered by a few trips to Google, but overall it was good to see the interest level from someone not in the usual web bubble PHP normally operates in. There were a few great debates that came out of her questions with the most memorable being about SEO. She had asked about our take on it and if it even played a part in the work that we did. Most at the table were of the opinion that, if it’s going to happen, it was someone else’s job – the responsibility of the front end folks as a part of making the site “pretty”.

This and another comment about application structure got me thinking…with a lot of the sites out there going with an MVC pattern for their structure, does this mean a sort of SEO-friendliness is already built in? I’m not talking that black magic, voodoo stuff that lots of firms pass off as SEO consulting. I mean the good placement of data, good content and a well though out site structure. By default, MVC makes this last one super simple. For most frameworks, it’s just a built in part of their routing to make search-engine friendly URLs. Of course, it’s still up to you to fill those URLs with good meaningful content, but it’s a start.

So, do we as developers still have a responsibility to create an application that will, in the end, make more sense to the outside world and to the major search engines? Should we step outside of our bubble and branch out into the wider ecosystem of the application, making sure that what we’re doing fits with the whole?

11 comments » | Development, PHP

The Myth of “Good Code”

November 1st, 2009 — 12:19am

There’s an interesting dichotomy in software development – anyone wh has spent any amount of time in the field knows it all too well. There comes a point in every project where you have to make a choice – good code or fast code. Sure, you’ll get those “sweet spot” projects that’ll let you work on the “good code” side of things for as long as you’ll need (maybe a personal project?) but more often than not, you’re going to fall on the “fast code” side of the line. It’s sad, really it is.

Every good developer knows that the world could only benefit from having more “good code” in the world. Applications would not only do what they’re supposed to to but they’d do it well and have better performance while doing it. Things would flow smoothly through the paths the user laid out in the planning stages and everything would be magically delicious. Right? Sadly, even when you have the time to make the “good code”, it’s still not that good.

First off, throw out those personal projects – the timelines of those don’t really apply anyway. You can hack away at a framework you’re developing for years and only get most of the way done with it. Unless it gets some kind of larger following, chances are people aren’t going to be putting the pressure on you to make updates and add new feature. The whole realm of personal project timelines is an interesting one – maybe something I’ll look into later on. For now, though, we’re going to focus on software someone else wants you to write. This is where the major part of the problem is – it’s someone else’s timeline, someone else’s thoughts you’re trying to put into code.

I can’t tell you the number of times that I’ve been working on a project and have hd nothing but the best of intentions of how it was going to turn out. I’d planned out the pieces, worked up descriptions of the objects involved and laid out how they’d all integrate together. The code was well-structured and was something that could be both easy to maintain and simple to expand – that is until the customer decided to get involved.

If you’ve worked on any kind of larger project for any length of time, you know the cardinal rule – the customer never knows what they want. Even when they say they do, show them a demo. Their minds will freak out with new possibilities and new features that were never even conceived of in the first versions you’ve developed. Now, this isn’t so much of a problem if you have the customer/client reined in to keep these sort of things under control, but if you don’t…let the bad code pour in.

It never fails – at least one of the new features that the customer proposes as a “strongly like and might need” for this version will go against the code that you’ve already written. I don’t think I’ve ever heard of a project that was able to augment what they were doing mid-stream (yes, even you agile folks) to accomidate every request the customer could make. Some things are easy, but most of these sort of changes are hard.

This is when it gets very hard to keep that “good code” in place. It takes a lot of practice and skill to keep things flexible enough to make the impact of these sort of changes minimal. Writing good code from the beginning is easy – making that good code stick through to the end is hard.

How hard are you willing to work to keep that code good?

Photo credit snappED_up

13 comments » | Development, PHP

Complacent Developers Suck

October 2nd, 2009 — 11:32pm

We’ve all been there – we’ve reached the top of our current skills. We’ve met every expectation and conqured every issue in front of us. We are masters of our domain and no problem seems too difficult. This is the worst position you can be in. No really, trust me on this one. As soon as you become complacent in your practices, you’re doing something wrong.

One of the key things that separates great developers from good developers is their capacity to learn. Good developers will learn how to do something and know it well. They’ll be content in their knowledge of how to debug a script a certain way or refactor their applications to follow a pattern they know well. Great developers, on the other hand, take that next step and grow. They leave their comfort zone in the dust and look to the future to find out how they can conquer the next hurdle in an elegant and constructive way. They’re the ones constantly improving themselves, working to make themselves and their code a better place to work and play. They see challenges in their development as things to innovate around not just as problems to solve with a certain equation. Their joy is in flexible, resilient code that can adapt to any situation and can make not only their lives simpler but the lives of those down the line easier and less complicated.

Innovation is the key here – any developer can cut and paste examples from other website to make things work. In fact, there’s a whole crop of developers out there that do nothing but this. They don’t innovate, they don’t learn – all they do is take the information they find and regurgitate it back into their code. As you can imagine, this is a very, very bad practice and can only lead to code that’s both difficult to maintain and hard to extend.

Be careful – don’t let your past accomplishments make you lax in your development. It’s easy to fall into the trap that successful code can lay. You see things working and the code seems solid so you go along your merry way and do the same on future projects. The only problem with the situation is the innovation – no two software projects are the same and no matter how similar they seem to be, code without innovation is no code at all. You learn something from each implementation and this new knowledge should be applied to every new project you encounter. Reusing code is good, updating it to reflect the knlowedge you’ve learned is even better.

Don’t be complacent in your development – learn, grow and use this knowledge in your future development. If you don’t, you’re only hurting yourself. Learning is good, applying is better. Constantly learn and innovate. This is the only true way to be a better developer. Period.

9 comments » | Development, PHP

Search or Settle?

August 6th, 2009 — 10:34pm

Let me start by posing a question to all of you other groups looking for PHP developers right now – should we just settle?

Sure, I’d love for that perfect candidate to come walking through the door, shiny resume in had that fits close to what we need (no, I’m not naive enough to think they’ll be perfect). We could sit there in the interview and he or she could give all the right answers in all the right places. The choice would be easy and, with a few shaking of hands, the deal would be sealed.

If that’s your impression of hiring a developer, you’re in for a serious kick in the shins by the software development industry. Right now (and it seems especially right now) finding good developers is even harder than the needle in the haystack trick. I’d go so far as to say that, for the parameters that most companies can afford, there’s almost no good, skilled developers out there – the real problem there being that pesky S-word.

If you’re not at all concerned about code quality or serious development, by all means hire the next interviewee that walks through your door. Don’t check his criteria, don’t look at his experience and by no means ask him any questions about how many years he’s been developing PHP. Now, a skilled developer, on the other hand, is something that should be sought after and held onto as long as possible. They’re the ones that will think about the structure of the code they’re writing and continuously look for ways to improve the application. As I explained it to a coworker of mine:

“You want a developer, not a hobbyist.”

I’m not saying that kids fresh out of school (or whatever) are to be discounted because they don’t have much development experience. I will say to be careful with them, though. As anyone that’s worked in development can tell you, there’s just that “something” you can see in the eyes of a developer when they talk about the technology they work with.

So, back to my dilemma – how to find a good developer in a wasteland of good talent. After a few interviews with widely varying candidates, I’ve been getting a bit more discouraged, but I just have to keep reminding myself of a few things:

  • Don’t be too picky (except on the important stuff)
  • No matter what the resume makes you think, don’t assume
  • Remember your roots, assess them based on theirs
  • Don’t settle.

Yes, I know I’m sort of answering my own question, but that doesn’t stop me from asking it. You go through enough applicants and your have to start wondering…

7 comments » | Development, PHP

Back to top