Let’s start out with the premise that every single bit of code in your application. By this I mean we have 100% code coverage for your application. This is difficult but achievable with lots of tests and proper use of mock objects.

Even with 100% code coverage, it still might not be enough. So much depends on your actual test cases. Have you anticipated edge cases that could cause your code grief? This is the one area of web applications that I think leads to the greatest amount of problems: determining edge cases when your code accepts user-generated content. So even if 100% code coverage can’t save you from every problem, what is a good compromise?

If you obsessively run PHPUnit code coverage reports like I do, you will be familiar with the CRAP index values for your code. Go read the article about it. I’ll wait.

I think that if you want to do effective testing, you can probably limit your code coverage efforts to class methods or functions that have a CRAP index of 5 of more. It’s a low enough value that you will end up testing a very large amount of your application’s code base and will be testing non-trivial code.

You don’t really need to test pass-through methods or functions (functions that are one-liners that return the response from another methods or functions) or getter / setter functions (if you’re into that sort of thing). Chances are they will get coverage in tests that call those methods.

In essence, don’t waste a lot of time writing tests that test the trivial or totally expected. You will have a much greater impact on your application by writing tests for the complicated parts of your application.

Finally, I encourage you to pursue another very impactful testing practice: whenever a bug is reported in your application, write a test to verify the bug. Then fix your application until the bug goes away. By doing things that way, you end up with a collection of tests that reflect the various ways that the users of your application actually, you know, use your application.

Good code coverage results in a feeling that only weird edge cases are going to bring your application crashing down. That frees you up to keep on building out the application instead of worrying if a minor change is going to wreak everything.

So the ultimate goal is TEST ALL THE THINGS THAT MATTER. Aim for that, and the rest will all fall into place.

First, I do almost all my work from a terminal. On my Macbook I use iTerm 2 instead of the stock Terminal.app. Until recently you could not get 256 colours without some external hacking and since I like my editor to have purty colours I needed a terminal to match it. I might take a look at Terminal.app again, but iTerm 2 fits the bill.

Why the terminal? PHPUnit is a CLI application. Yes, many popular editors and IDE’s can do things like execute PHPUnit for you, but they are limited in what flexibility they provide. At Kaplan we have several different configurations under which we can run our tests. Again, reduce the friction between the tools and you using them.

Then we have the One True Editor. While I do use other editors from time to time (I do like Sublime Text 2 a lot because it has Vim bindings), I stick with Vim. Why? The plugins.

Here’s what I use:

• Pathogen to make loading other plugins easy
• DiffDir for making code review and test reviews easier
• Gist.vim
• closetag
• inline_edit.vim
• nerdtree
• supertab
• surround.vim - it has ruined me for using other editors
• Tabular.vim
• tagbar - INDISPENSABLE
• vim-repeat
• vim-taglist
• vim-unimpaired

There is nothing specific to doing TDD in these plugins, but what they do for me is allow me to slice and dice text as quickly as possible, along with providing me with easy ways to navigate through the code base. Remember, reducing friction is a big thing to me. If the tool makes it tough for me to do what I want, it will be the target of grumpy ranitng.

One of the reasons I like Sublime Text 2 is that you can jump all over the place in the code base in similar ways. If you editor doesn’t allow you to do that, you need to get rid of that editor and use something that does. NO EXCUSES.

A typical coding session has me using two terminal windows. One has Vim running in it, the other is used to run PHPUnit or other testing framework of choice as I venture in the world of BDD and testing in other languages. Then I do the following:

• figure out HOW to test the code I’m writing
• write the tests required
• write code until the tests pass
• refactor code as required
• refactor tests as required.

That’s really all their is to it. The actual work flow of when you are using TDD isn’t magical. I will admit that experience is the only teacher for how to actually write the tests, but luckily I have an awesome co-worker who bellows obscenities at me while guiding me down the path to total testing mastery. I know Will, you only hate me because you love me.

Every time I make a change to a test or the code, I re-run the tests. I find that this lets me get more done while actually slowing down the pace. You end up more focussed on the bit of code that really needs your attention, instead of getting drawn into blind alleys.

I also frequently run code-coverage reports to make sure that I’m getting maximum coverage for my efforts, while ignoring writing tests specifically for methods with very low CRAP indexes. Again, I’m making sure that I am targeting the parts of my code that need to be tested.

I know I’ve written about this before, but when you approach things from a TDD perspective, you find that using things like dependency injection become second nature.

If there is a lesson to be learned from this, it’s to make sure that every tool that you use reduces the friction that is generated when building your application using TDD.

So natually I started arguing. I was rude. He was rude, slapping me in the twitter face with a blog link that seemed to indicate he thought I had no idea about variables in PHP. To be fair I earned that by not paying attention. Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn’t have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn’t mash the logging level together with the message.

Anyway, I’m not going to do that bit of work here. Instead, I want to show that it is not enough to teach an idea to someone. You have to show them how to test their idea once it’s been refactored to make sure nothing has changed. First, let’s start with a working example of his logging class, using the dreaded switch-case.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<?php

// Sample logger class that uses a switch-case
require_once 'LoggingException.php';

class LoggerSwitch
{
  public function logMessage($message = "CRITICAL::The system encountered a problem")
  {
      $parts = explode('::', $message);
      $level = strtolower($parts[0]);
      $logMessage = $parts[1];

      switch ($level) {
          case 'notice':
              return $this->_writeToLog($level, $logMessage);
          case 'critical':
              $this->_writeToLog($level, $logMessage);
              return $this->_emailOps($message);
          case 'catastrophe':
              $this->_writeToLog($level, $logMessage);
              $this->_emailOps($logMessage);
              return $this->_textCeo($message);
      }

      throw new LoggingException("Unknown logging level {$level}");
  }

  protected function _writeToLog($level, $logMessage)
  {
      return "Wrote {$logMessage} to {$level} file";
  }

  protected function _emailOps($logMessage)
  {
      return "Sent email to Ops";
  }

  protected function _textCeo($message)
  {
      return "Sent text to CEO";
  }
}

Here’s the tests for it

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

<?php

// PHPUnit test for logger-switch.php

require '../logger-switch.php';

class LoggerSwitchTest extends PHPUnit_Framework_TestCase
{
  public $logger;

  public function setUp()
  {
      $this->logger = new LoggerSwitch();
  }
  
  /**
  * Data provider for testing our logging object
  */
  public function loggerTestingScenarios()
  {
      return array(
          array(
              'NOTICE::test notice message',
              'Wrote test notice message to notice file'
          ),
          array(
              'CRITICAL::test notice message',
              'Sent email to Ops'
          ),
          array(
              'CATASTROPHE::test notice message',
              'Sent text to CEO'
          ),
      );
  }

  /**
  * @test
  * @dataProvider loggerTestingScenarios
  * @param $message          string
  * @param $expectedResponse string
  */
  public function testReturnsExpectedResponseBasedOnMessage(
      $message,
      $expectedResponse)
  {
      $response = $this->logger->logMessage($message);
      $this->assertEquals(
          $expectedResponse,
          $response,
          'Did not get expected response'
      );
  }

  /**
  * @test
  */
  public function testThrowsExceptionWhenUnknownLevelSubmitted()
  {
      $this->setExpectedException('LoggingException', 'Unknown logging level test');
      $response = $this->logger->logMessage('TEST:: test message');
  }
}

These tests give us 100% test coverage, in case you were wondering.

Okay, so the next step is to refactor our incredibly stupid logging class to use the Strategy pattern.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

<?php

// Logging class that uses the strategy pattern
require_once 'LoggingException.php';

class LoggerStrategy
{
  public function logMessage($message = "CRITICAL::The system encountered a problem")
  {
      $parts = explode('::', $message);
      $level = strtolower($parts[0]);
      $method = sprintf('_log%sMessage', ucfirst($level));

      if (!method_exists($this, $method)) {
          throw new LoggingException('Unknown logging level ' . $level);
      }

      return $this->$method($parts[1]);
  }    

  protected function _logNoticeMessage($message)
  {
      return $this->_writeToLog('notice', $message);
  }

  protected function _logCriticalMessage($message)
  {
      $this->_writeToLog('critical', $message);
      return $this->_emailOps($message);   
  }

  protected function _logCatastropheMessage($message)
  {
      $this->_writeToLog('catastrophe', $message);
      $this->_emailOps($message);
      return $this->_textCeo($message);
  }

  protected function _writeToLog($level, $logMessage)
  {
      return "Wrote {$logMessage} to {$level} file";
  }

  protected function _emailOps($logMessage)
  {
      return "Sent email to Ops";
  }

  protected function _textCeo($message)
  {
      return "Sent text to CEO";
  }
}

The thing that lept out at me was that this refactor worked, but resulted in more code. The good characteristic is all the small methods without lots of code in them. Even better is that we don’t have to change any of our tests, everything worked the same! All we had to do was change which object we were using for $this->logger.

If you want to see the code for this blog post for yourself (it does work and run using PHPUnit) you can grab it from Github. Also, feel free to take a look at the code coverage report as proof that I did cover everything I should have.

I’ve spent quite a bit of time in the last few years helping to spread the word that having automated test suites and testable applications is a good thing. I know it’s not easy and I’ve had conversations with many other developers who still think that writing tests is a waste of time, not appropriate for their unique situation, and so on and so forth.

If I were to make some sweeping generalizations about those people who feel that test-driven development is a waste of time, I would call them supremely overconfident in their own abilities in the face of plenty of evidence that suggests otherwise. Many developers that I respect immensely still seem to think that Getting Shit Done Does Not Include Writing Tests.

I will return to that topic later.

I don’t remember when it was that I exactly discovered SimpleTest while working at an online dating site. I do remember it was in 2003. If I had to make an educated guess it was because I had gotten tired of testing everything through a browser. Loading the same pages OVER AND OVER AND OVER again, hoping I had covered all the scenarios for the incredibly crummy code I was writing (this was quite early in my programming career) in my manual testing. Only to find that I had missed something and it was causing problems on the live site.

Once I discovered unit testing, it was like a bit was flipped in my brain. I immediately understood the benefits of a test suite that we could run from the browser AND provide proof that all was good. No more manual testing unless absolutely necessary!

It took some time and some lobbying but not too long before I left, the application architect they had hired decided that we needed to write a bunch of tests using SimpleTest as part of progressing towards a refactoring and rewrite of the application itself, since it really was the type of spaghetti PHP application the language is derided for encouraging.

I don’t know what happened to all those tests after I left. I would keep running into people who I worked with there and new hires and would sometimes ask what was going on. Never did ask about tests though, as I assumed that they were either still there but not being used, or ripped out under the guise of Getting Shit Done Does Not Include Writing Tests.

So why am I still in the minority that values testing? I think it’s because many people blind themselves to the reality of how much work they are really getting done. Writing tests as part of the development process, in my opinion, simply moves the debugging of your application from after you’ve written the code to while you are still writing it.

Look, it still takes the same amount of time to write code + debug whether you use TDD or GSDDNIWT. Be honest with yourself. Every time you are up until the early hours of the morning trying to fix a problem is an opportunity to be really honest with yourself and say “how can I avoid this?” instead of saying “oh well, this is how it really is.” I believe that having tests will reduce the amount of time you spend trying to understand why things are not working the way that you expect them to.

If anything, the rise of startup worship makes the job of people like me even tougher. Minimum Viable Product goes hand-in-hand with GSDDNIWT. I cringe when people forward me conversations with their bosses and co-workers that seem to imply that only inexperienced developers really need tests. “Rockstars have the codebase memorized and can intuitively make changes that won’t break anything.” Really?

I can only speak for myself, but testing is my way of not having to remember the entire code base. It lets me examine discrete modules of code and see clear examples of how they work and how they are supposed to interact with other modules. When it’s crunch time and something absolutely needs to work, my memory is the last thing I want to be relying on to tell me where to look for the problem.

I could write a very long ranty blog post about testing but I will save my energy for those ready to be converted instead of those who have decided to rely on their immense programming skills and eidetic memory about their application. Lesser mortals like me will knit themselves a comfy blanket using tests and simplified application models and hopefully be sound asleep while my rockstar compatriots are up at 2am debugging their application after a painful production launch.

I prefer working in collaborative environments where the entire team gets to work on the entire application. None of this siloing bullshit that I see happen time and time again. “Borat is the only guy who understand our reporting system. We can’t possibly let anyone else work on it!” That sort of nonsense doesn’t belong on any team and also speaks of ridonkulous communication problems.

At Kaplan Professional they’ve chosen to use pair programming as a normal, everyday development practice. Our team consists of 3 developers in the main offices in La Crosse, 7 remote workers spread across 3 time zones, 2 QA staff, one testing engineer, and our development manager. Pair programming has worked out awesomely and I want to try and explain why.

One of the biggest hurdles facing a team with in-house and remote workers is communication issues. Your classic pair programming setup is two developers sitting together at the same desk, one typing while the other helps out with suggestions on how to write the tests we’re going to need and how to hand-crafted our artisanal code. Sadly we still have people writing the tests AFTER they’ve written the code, but grumpiness is not eliminated in one day.

At Kaplan we use the dynamic duo of Join.me and TeamSpeak for pair programming. Whomever is driving will start a join.me session, share the link with their partner and away they go. There is much coding and playful banter as Shit Gets Done. I cannot put it any other way.

Your partner keeps you honest and focussed on the task you’re trying to solve. For example, when I was coding a feature I was not 100% familiar with I was able to get my pair to do research on other parts of the code base while I was creating the skeletons for some tests. Many times my pair would suggest “don’t you think we could make that bit of code better by…”, and more often than not we’d have a good discussion about writing easy-to-understand-yet-efficient code or discuss how what we are doing is out of character with the rest of the code. Object calisthenics is a favourite topic of mine and has led some of my other fellow developers to rethink how they have been building things.

See, people have this idea that pair programming means that one guy codes while the other sullenly watches or surfs the internet instead. Or it means two developers fucking around instead of working. I cannot speak for other developers, but I don’t put up with that shit while paired. I am expecting my pair to devote as much attention to the task at hand as I am, and I return the favour by being attentive and helpful towards my pair when I am not driving the session.

Because developers are taking turns solving problems and implementing solutions, the amount of tribal knowledge (knowledge about the application itself locked up in people’s brains instead of shared and/or documented) decreases and everyone’s understanding of the system goes up. This transfer of knowledge can only really happen as one developer shows another just what the hell is going on inside this application. There is no better way I can think of to do this than while paired.

Pair programming also has the added good side effect of allowing team members to get to know each other. It’s only the most anti-social of co-workers who won’t end up discussing things outside of work while pair programming. I don’t see any reason to work with robots who only care about how many story points we are cranking out every sprint. We are people first and coders second. Don’t forget that.

Finally, pair programming results in more than one person understanding how a particular problem was solved and how the solution was implemented. At Kaplan we always have a sprint demo day at the end where we demonstrate the various features that were implemented during the sprint. With everyone having used pair programming, it’s much easier for the group as a whole to decide who will demonstrate what. No need for one developer to hog all the glory!

This also ends up being a great way for those who already understand the application to teach new hires how things work. Kaplan Professional had expanded its team quite rapidly when I started and I think that without pairing we would still be struggling to meet our sprint commitments. Nothing prompts rage-quitting more than a situation where it is incredibly difficult for new hires to make positive contributions to the team within a few days of starting.

I understand that not every organization is ready to make a commitment to use pair programming. Just like not every organization is ready to make a commitment to writing tests as part of their normal flow. But don’t harbour any misconceptions about what pair programming really is: two developers working together towards solving problems, alternating who is mashing keys on a keyboard. Both developers are working, they are just working together.

The goal is to solve problems within a unit of time that you have committed to. Kaplan Professional is no different in that it expects you to honour your commitments. Pair programming has been a way for problems to get solved faster than if individual programmers had been trying to solve them. Communication is up, non-working features are done, and the amount of work actually getting done has increased noticeably in the two months since I started working in pairs.

I cannot recommend enough giving pair programming an honest try in your work environment. You might be surprised to find out that you are Getting More Shit Done than you realize.

My old boss Ben Ramsey did a very informative post on getting PHP 5.4 configured on CentOS so I decided to one-up him by taking his instructions and creating a Puppet manifest so you could do this using Vagrant or on any server that you can provision using Puppet.

First, you will need a CentOS base box to play with. I used this box but I think any CentOS 6.0 (or above) base box will do. If you are feeling really adventurous you could grab an ISO and use Vewee and follow these instructions to create your own.

Whatever box you choose, the next step is to create the directory where your VM will run and run ‘vagrant init’ with the name of the box and then edit the Vagrantfile. Here’s a condensed version of my Vagrantfile

1
2
3
4
5
6
7
8
9
10
11

Vagrant::Config.run do |config|
  config.vm.box = "centos-60-x86_64"

  config.vm.forward_port 80, 8080
  config.vm.forward_port 8000, 8000

  config.vm.provision :puppet do |puppet|
     puppet.manifests_path = "manifests"
     puppet.manifest_file  = "default.pp"
  end
end

Those port forwards are identical to the ones that Ben suggested using. You can get rid of the one that maps port 8000 if you don’t feel like playing around with the new built-in web server introducted in PHP 5.4.

Now, create the manifests directory inside the directory where you are placing the new VM and add a file called default.pp that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

# Puppet manifest for my PHP dev machine

class httpd {
  exec { 'yum-update':
    command => '/usr/bin/yum -y update'
  }

  package { "httpd":
    ensure => present,
  }

  package { "httpd-devel":
    ensure  => present,
  }
}

class phpdev {
  package { "libxml2-devel":
    ensure  => present,
  }


  package { "libXpm-devel":
    ensure  => present,
  }

  package { "gmp-devel":
    ensure  => present,
  }

  package { "libicu-devel":
    ensure  => present,
  }

  package { "t1lib-devel":
    ensure  => present,
  }

  package { "aspell-devel":
    ensure  => present,
  }

  package { "openssl-devel":
    ensure  => present,
  }

  package { "bzip2-devel":
    ensure  => present,
  }

  package { "libcurl-devel":
    ensure  => present,
  }

  package { "libjpeg-devel":
    ensure  => present,
  }

  package { "libvpx-devel":
    ensure  => present,
  }

  package { "libpng-devel":
    ensure  => present,
  }

  package { "freetype-devel":
    ensure  => present,
  }

  package { "readline-devel":
    ensure  => present,
  }

  package { "libtidy-devel":
    ensure  => present,
  }

  package { "libxslt-devel":
    ensure  => present,
  }
}

class rpmforge {
  exec {
    "/usr/bin/wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm":
      alias   => "grab-rpmforge",
  }

  exec {
    "/bin/rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt":
      alias   => "import-key",
      require => Exec["grab-rpmforge"],
  }

  exec {
    "/bin/rpm -i rpmforge-release-0.5.2-2.el6.rf.*.rpm":
      alias   => "install-rpmforge",
      require => Exec["import-key"],
  }

  package { "libmcrypt-devel":
    ensure  => present,
    require => Exec["install-rpmforge"]
  }
}

include httpd
include phpdev
include rpmforge

Now, there appears to be a lot of stuff going on in there, but it’s actually quite simple. I broke things down into 3 distinct groups.

The first group ( which I called ‘httpd’) makes sure that we install Apache 2 and the development libraries and header files that will be needed to compile PHP. Then we open up the firewall to allow access to the VM on those two ports. By default Vagrant maps port 22 on the VM to port 2222 on the VM, so no need to add that in.

The next group (phpdev) is installing all the support libraries that Ben recommended in his own article.

Finally we need to execute a few commands to allows us to also install libmcrypt-devel because it is not part of the standard CentOS distribution, but is available via RPMForge.

Save that file (make sure there are no typos either from me or from you!), then type ‘vagrant up’ and it will try and it will try to provision your new server with this Puppet manifest and add in all your files.

Then you can follow the rest of Ben’s instructions on how to compile PHP 5.4 (I installed PHP 5.4.1RC1 just to be living on the edge) and don’t forget to verify that your Apache setup is configured to all you to serve up PHP files.

I think that you can have a cutting-edge CentOS VM with the latest PHP installed on it up and running in under an hour from starting to download your CentOS Vagrant base box to verifying your test file with phpinfo() in it worked.

Here is the constructor method that we are trying to test:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php

class Alpha
{
    protected $_foo;
    protected $_bar;
    protected $_baz;

    public function __construct()
    {
        $container = Grumpy_Container::getInstance();
        $alphaConfig = $container->alphaConfig();
        $this->_foo = $alphaConfig->foo;
        $this->_bar = $alphaConfig->bar;
        $this->_baz = $alphaConfig->baz;
    }

    // the rest of our class is here
}

In this example, Grumpy_Container is an object that is available via autoloading and it is used as a dependency injection container (DIC).

Okay, so how do we test that the constructor is doing what it is supposed to? We would want to verify that those protected class attributes have been set to values we are expecting.

In order to do that we will also need to override the values in our DIC so when we run the test we have values in there we are expecting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<?php

public testConstructorAssignsExpectedAttributeValues()
{
    $container = Grumpy_Container::getInstance();

    // Create our mock configuration object
    $alphaConfig = new stdClass();
    $alphaConfig->foo = 'testfoo';
    $alphaConfig->bar = 'testbar';
    $alphaConfig->baz = 'testbaz';

    // Place this back in the container to override what we have
    $container->alphaConfig = function() use ($alphaConfig) {
        return $alphaConfig;
    };

    // Create our mock object
    $alphaTest = $this->getMockBuilder('Alpha')
        ->disableOriginalConstructor()
        ->getMock();

    // Manually run the constructor
    $alphaTest->__construct();

    // Check for values we expect
    $this->assertAttributeEquals(
        $alphaConfig->foo,
        '_foo',
        $alphaTest,
        'Should set expected foo config value'
    );

    $this->assertAttributeEquals(
        $alphaConfig->bar,
        '_bar',
        $alphaTest,
        'Should set expected foo config value'
    );

    $this->assertAttributeEquals(
        $alphaConfig->baz,
        '_baz',
        $alphaTest,
        'Should set expected bar config value'
    );

}

The magic method here is assertAttributeEquals(). It lets you check the value inside any protected or private class attributes, which is absolutely a requirement in this example. It is probably better to have some other publicly-available methods that can return us the protected (or in some cases private because you don’t want anyone to manipulate them) attributes.

Hope this helps you understand some ways to test your constructors.

With such an extensive array of tests, I have received an education in what it really means to write unit tests for live, production-ready code that really takes unit testing seriously. I think that the biggest problem that most developers face when getting into Test Driven Development is not understanding of how to efficiently use mock objects.

If you are really writing your unit tests the way you should, each test is focusing on testing one bit of functionality in isolation, which means that you will be heavily relying on mock objects to make things work. I’ve come up with an example scenario that I hope goes a long way to explaining how to effectively use mock objects.

In these examples I am using PHPUnit’s built-in support for mock objects. At Kaplan our testing engineer told me that he had tried to use Mockery but there were problems getting it to play nicely with the dependency injection container that is in use (it’s a customized version of Pimple). Can’t argue with that. Not until I experiment with Mockery myself to see if it gains us anything instead of using what comes with PHPUnit.

So here is our scenario: we have a class called Alpha, that contains a method called munge(). We wish to test that method in a unit test. So what does this class look like?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php

class Alpha
{
    // Omit code showing constructor...

    public function munge(Foo $foo, Bar $bar)
    {
        $fooDetails = $foo->getDetails();
        $fooId = $foo->getId();

        $barStartDate = $bar->getStartDate();
        $barEndDate = $bar->getEndDate();

        $source = "{$fooId}|{$fooDetails}|{$barStartDate}|{$barEndDate}";

        return md5('rocksalt' . $source);
    }
}

My grumpy tester’s eye looks at that and immediately says “we will need to mock those Foo and Bar objects to make this test work.” First we need to look at the Foo object

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php
class Foo
{
    // Omit code showing how we construct a Foo object

    public function getId()
    {
        return $this->_id;
    }

    public function getDetails()
    {
        $tree = $this->_tree;
        $branch = $this->_branch;

        return $tree . '->' . $branch;
    }
}

So it looks like this class represents one “Foo” object in the system. I omitted the constructor as it’s not really important to the lesson I’m trying to teach here. Let’s assume we have a way to generate a Foo object via some sort of mapper.

Our Alpha->munge() method expects to be passed in a Foo object and to retrieve info via getDetails() and getId() calls. Let’s start our test and mock that up.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 
<?php
class Test extends PHPUnit_Framework_TestCase
{

    public function testAlphaMunge()
    {
        $mockFoo = $this->getMockBuilder('Foo')
            ->disableOriginalConstructor()
            ->getMock();
        $mockFoo->expects($this->atLeastOnce())
            ->method('getDetails')
            ->will($this->returnValue('1->2'));
        $mockFoo->expects($this->atLeastOnce())
            ->method('getId')
            ->will($this->returnValue('1'));

        // More test fun to come
    }
}

When you build a mock for use in your test, you generally have to do two things:

• create a mock of the object itself
• tell it what to do when specific methods are called

What I’ve done here is pretty standard EXCEPT for the use of that disableOriginalConstructor() method. Why is it used? Well, sometimes when you are creating a mock of an object it will often have a constructor that accepts parameters. I’m not testing to see if we can create the object, I merely am trying to simulate some of the methods of that object.

Once I’ve created the mock of the object, I then tell it what to do when I make certain method calls. Clearly I’ve just pulled some arbitrary values out of my ass for this example, but usually you can figure out what some reasonable return values are supposed to be by, you know, actually looking at the code you are mocking.

So what does our Bar object look like?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
class Bar
{
    // Same drill, no need to show constructor details

    public function getStartDate()
    {
        return $this->_startDate;
    }

    public function getEndDate()
    {
        return $this->_endDate;
    }
}

Time to add a mock Bar to our test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?php
class Test extends PHPUnit_Framework_TestCase
{
    public function testAlphaMunge()
    {
        $mockFoo = $this->getMockBuilder('Foo')
            ->disableOriginalConstructor()
            ->getMock();
        $mockFoo->expects($this->atLeastOnce())
            ->method('getDetails')
            ->will($this->returnValue('1->2'));
        $mockFoo->expects($this->atLeastOnce())
            ->method('getId')
            ->will($this->returnValue('1'));

        $mockBar = $this->getMockBuilder('Bar')
            ->disableOriginalConstructor()
            ->getMock();
        $mockBar->expects($this->atLeastOnce())
            ->method('getStartDate')
            ->will($this->returnValue('2012-03-27'));
        $mockBar->expects($this->atLeastOnce())
            ->method('getEndDate')
            ->will($this->returnValue('2012-04-09'));

        // More test fun to come
    }
}

A quick note about $this->atLeastOnce(): when you mock the objects you can tell it how often you expect that method to be called. I had a long discussion about this with our testing engineer Will Parker after I posted the orginal version of this post.

We have multiple options

• $this->once() - should be used only when you REALLY want that method to be called once
• $this->atLeastOnce() - should be used when you need to do it once but aren’t sure how many times
• $this->any() - you really don’t care how many times it’s called

If you’re lazy, you’ll go with $this->any() so you don’t have to worry about it. After a discussion with Will, I have come to like the use of $this->atLeastOnce(). It’s not a deal-breaker no matter which one you choose, a lot of it comes down to personal preferences.

So now we have our two objects mocked. Now we can go back to our test and add in the creation of our Alpha class, inject the two mocks into the method we are testing, and check for expected results.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

<?php
class Test extends PHPUnit_Framework_TestCase
{
    public function testAlphaMunge()
    {
        $mockFoo = $this->getMockBuilder('Foo')
            ->disableOriginalConstructor()
            ->getMock();
        $mockFoo->expects($this->atLeastOnce())
            ->method('getDetails')
            ->will($this->returnValue('1->2'));
        $mockFoo->expects($this->atLeastOnce())
            ->method('getId')
            ->will($this->returnValue('1'));

        $mockBar = $this->getMockBuilder('Bar')
            ->disableOriginalConstructor()
            ->getMock();
        $mockBar->expects($this->atLeastOnce())
            ->method('getStartDate')
            ->will($this->returnValue('2012-03-27'));
        $mockBar->expects($this->atLeastOnce())
            ->method('getEndDate')
            ->will($this->returnValue('2012-04-09'));

        $source = "1|1->2|2012-03-27|2012-04-09";
        $expectedMunge = md5('rocksalt' . $source);

        $testAlpha = new Alpha();
        $munge = $testAlpha->getMunge($mockFoo, $mockBar);

        $this->assertEquals(
            $expectedMunge,
            $munge,
            'Munge value should match expected'
        );
    }
}

And there you have it! A test for a specific method that uses mocks to properly isolate functionality that is required for the test to work.

I hope this blog post makes things a lot clearer when it comes to understanding the role of mocks when creating unit tests.

With the new position comes more of the stuff I am really passionate about: testing and automation. Which also got me to thinking about the reasons why I am so passionate about these things.

I thought I would create my own little testing mini-manifesto here. The ideas my podcasting partner did with his MicroPHP Manifesto made me realize that sometimes it is good to write these things down, as it were.

I test because the tools are easy to use

I write tests because the tools that exist today to write them are easy to install and testing techniques are easily taught.

I test because I don’t like surprises

I write tests to make sure what I am building behaves the way I am expecting.

I test because I want people to understand what I’ve done

I write tests so they can act as documentation for how to use things that I have built.

I test because I want to be able to change things fearlessly

I write tests so that I can experiment and change things, knowing I have a way of telling myself if I’ve done something wrong.

I test because automation is a secret weapon

I write tests so I can create an automated developer workflows that will reduce the likelihood that something horribly broken makes it into production.

I test because it forces me to focus on design

I write tests to force me to loosely couple my components and create simple systems that can display complex behaviour.

I test because to me it is the right thing to do

I write tests because applications with a high level of test code coverage have significantly reduced bug-fix cycles and turn production deployments into non-events that happen multiple times a day.

I hope my mini-manifesto at least makes you think about where testing fits into modern web application development.

I have been trying to push my JavaScript skills lately by first playing around with Node.js to get a feel for event-driven server-side coding and by trying to build something semi-useful using Knockout. Knockout is a client-side Model-View-View-Model framework that promotes four really good principles: declarative bindings, automatic UI refreshing, dependency tracking and templating. Check out the documentation on the Knockout web site for a great explanation of why those are good thigns.

A typical Knockout-out powered site is one where the client-side code talks to a server-side API. My experimental site for this is one that uses an API written in PHP using Slim. Of course, I cannot do this without writing some tests. My first set of tests are for the calling of the API itself.

After working with PHPUnit’s “assert that the result matches expectations” philosophy, switching to using a behavioural approach has changed how I decide to approach actually testing something. Let me show you what I mean.

Here’s a test for an API call to get our “current” set of transactions, which is hard-coded in the system to be all trades that have occurred in the past 3 weeks.

1
2
3
4
5
6
7
8
9
10

Feature: transactions API 

Scenario: 
  Given I call "/transactions/current"
  Then I get a response
  And the response is JSON
  And the response contains at least one transaction
  And the first transaction contains a transaction ID
  And the first transaction contains two teams
  And the first transaction contains a description

If you read that out loud it sounds like how you would describe to a co-worker what you were expecting to happen on an API call, albeit a little more stilted and formalized.

When you first write a feature like this and then ask Behat to run all the tests on it, if there is no code to execute a specific step it will give you the skeleton of code to make it happen. Then it is up to you to implement the actual code that will make the tests run.

Here’s the final product:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115

<?php

use Behat\Behat\Context\ClosuredContextInterface,
    Behat\Behat\Context\TranslatedContextInterface,
    Behat\Behat\Context\BehatContext,
    Behat\Behat\Exception\PendingException;
use Behat\Gherkin\Node\PyStringNode,
    Behat\Gherkin\Node\TableNode;

//
// Require 3rd-party libraries here:
//
//   require_once 'PHPUnit/Autoload.php';
//   require_once 'PHPUnit/Framework/Assert/Functions.php';
//

/**
 * Features context.
 */
class FeatureContext extends BehatContext
{
    /**
     * Initializes context.
     * Every scenario gets it's own context object.
     *
     * @param   array   $parameters     context parameters (set them up through behat.yml)
     */
    public function __construct(array $parameters)
    {
        // Initialize your context here
    }

    /**
     * @Given /^I call "([^"]*)"$/
     */
    public function iCall($argument1)
    {
        $client = new Guzzle\Service\Client();
        $request = $client->get('http://local.ibl-delphi' . $argument1)->send();
        $this->response = $request->getBody(true);
    }

    /**
     * @Then /^I get a response$/
     */
    public function iGetAResponse()
    {
        if (empty($this->response)) {
            throw new Exception('Did not get a response from the API');
        }
    }

    /**
     * @Given /^the response is JSON$/
     */
    public function theResponseIsJson()
    {
        $data = json_decode($this->response);

        if (empty($data)) {
            throw new Exception("Response was not JSON\n" . $this->response);
        }
    }

    /**
     * @Given /^the response contains at least one transaction$/
     */
    public function theResponseContainsAtLeastOneTransaction()
    {
        $data = json_decode($this->response);

        if (count($data) < 1) {
            throw new Exception("Response did not contain at least one transaction");
        }
    }

    /**
     * @Given /^the first transaction contains a transaction ID$/
     */
    public function theFirstTransactionContainsATransactionId()
    {
        $data = json_decode($this->response, true);
        $transaction = $data[0];

        if (!isset($transaction['id'])) {
            throw new Exception("First transaction did not contain a transaction id");
        }
    }

    /**
     * @Given /^the first transaction contains two teams$/
     */
    public function theFirstTransactionContainsTwoTeams()
    {
        $data = json_decode($this->response, true);
        $transaction = $data[0];

        if (!isset($transaction['tradePartner1']) && !isset($transaction['tradePartner2'])) {
            throw new Exception("First transaction did not contain two teams");
        }
    }

     /**
     * @Given /^the first transaction contains a description$/
     */
    public function theFirstTransactionContainsADescription()
    {
        $data = json_decode($this->response, true);
        $transaction = $data[0];

        if (!isset($transaction['description'])) {
            throw new Exception("First transaction is missing a description");
        }
    }
}

Notice how Behat uses annotations that describe what type of scenario the method uses. It also uses regular expressions to extract specific values that you are wishing to test. Those are typically values inside quotes in the actual features.

If you are wondering what the skeletons (or stubbs depending on what terminology you like to use) looked like before I wrote code to implement them, you can simply cut-and-paste the scenario file at the top of this post into a feature file (don’t forget to give a .feature extension) and it will show you all of them.

I liked this method because it meant I could easily add more tests and Behat would tell me what code woudl be needed to run it.

So what does the output look like for the test?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-> % bin/behat
Feature: transactions API

  Scenario:                                             # features/transactions.feature:3
    Given I call "/transactions/current"                # FeatureContext::iCall()
    Then I get a response                               # FeatureContext::iGetAResponse()
    And the response is JSON                            # FeatureContext::theResponseIsJson()
    And the response contains at least one transaction  # FeatureContext::theResponseContainsAtLeastOneTransaction()
    And the first transaction contains a transaction ID # FeatureContext::theFirstTransactionContainsATransactionId()
    And the first transaction contains two teams        # FeatureContext::theFirstTransactionContainsTwoTeams()
    And the first transaction contains a description    # FeatureContext::theFirstTransactionContainsADescription()

1 scenario (1 passed)
7 steps (7 passed)
0m0.362s

I have obviously only scratched the surface of what can be done with Behat. I myself have questions about how to prevent the FeatureContext.php file, which contains all the functionality that drives the tests, from getting too large. I can also see the lure of endlessly tweaking the scenarios to reduce the amount of code required to run them all.

What about code-coverage reports? Easily available in PHPUnit but is it possible using Behat? It’s still early days for some of the alternatives to PHPUnit.

The example above is only the first of numerous tests that will be written for this side project, as it needs to cover displaying archived transactions to be voted on, user authentication, and the voting process itself.

I think that the BDD approach maps better to a results-oriented methodology when it comes to testing: you are using real-life scenarios to make sure that you are getting back the results you are expecting. In the end. that is still the goal of testing.

When you are testing an API you main concern is your ability to reproduce the results of a specific API call. If your API is such that repeating a call several times will give you different results, you do have some challenges on your hands.

Testing that an API just works is what I would call a functional test. At the highest level you are saying “will this call actually work”. Since you will be actually making API calls in your tests they can take quite some time to run depending on how many you have. Long-running tests are the type of tests that really should be forming the last line of defense just before you’re about to go into production.

Why? Functional tests have a lot of moving parts: HTTP calls, request and response parsing, and likely communications with some sort of data store. Not exactly the types of things that lead you to having a test suite that can run in 10 seconds or less.

In my opinion the only way to have really effective functional tests is by making sure that the API endpoints you are testing are using a known data source, one that will not be altered by your tests. That way it will be easy to verify that a particular call had the expected response. Remember, at the most basic level testing is about repeatedly verifying that your code is returning an expected result.

If you are testing someone else’s API, I hope there is a test mode or a sandbox that you can use. A lot of APIs are rate-limited or only allow a limited number of requests a day (I’m looking at you, Google Analytics). The last thing you want is for your application to longer be able to access an API because you went nuts testing things. Remember, the goal of functional tests in this scenario are to make sure that the API is returning results that you expect, nothing more.

Integration tests of APIs are a bit of a tricky thing to do in an effective way. Sometimes 3rd party APIs change. Sometimes you are also lucky enough to be told ahead of time that it’s happening. If your application relies heavily on 3rd party APIs then your integration tests are a key line of defense. While tests like these shouldn’t be run as much as the unit tests for the API, they should be run before a production push. Nobody likes their application to be broken because of an unannounced change to an API.

Finally, we have tests designed to make sure that your application is correctly handling the results of API calls. To make these sorts of tests work, you will end up either creating mock objects of the code that will do the calls or data fixtures representing results of API calls. It is also for this reason I always recommend wrapping the calls to an API in code, just so you can mock them for testing purposes. Sure, it might be easier to cheat and do file_get_contents() on a URL but that approach is pretty difficult to test.

Remember, these tests should not even be calling out to an API in order to work. Mocks and data fixtures are supposed to provide that data. All you are doing is testing the code that needs results from the API. Again, if you have been building your application with testability in mind your suite of unit tests should be blazing fast.

In the end, it doesn’t really matter what tools you are using to test either your own APIs or ones that your application depends on. Be clear in your mind about what it is you are actually trying to accomplish and don’t get create tests that provide very little value to your application.

I decided to use the following things for this app:

• Slim (using latest stable version, 1.5.0 at this writing)
• Pimple as a dependency injection container
• Twig for a templating engine

I also decided to use Composer as a way to install the above dependencies. Slim is not in Packagist so I was forced to do a little reorganizing work after getting some help in IRC from Jake Smith. Here’s what I did to get all three of those things playing nicely together with Composer’s autoloader:

• moved the directory that contains Slim into the vendor directory
• altered vendor/.composer/autoload_namespaces.php to look for Slim

1
2
3
4
5
6
7
8
9
10

// autoload_namespace.php generated by Composer

$vendorDir = dirname(__DIR__);

return array(
    'Twig_Extensions_' => $vendorDir . '/twig/extensions/lib/',
    'Twig_' => $vendorDir . '/twig/twig/lib/',
    'Pimple' => $vendorDir . '/pimple/pimple/lib/',
    'Slim' => $vendorDir .'/slim/slim'
);

I’ve come to the opinion that if you are using a tool that provides an autoload you are probably better off using the one they provide rather then trying to make those two co-exist. I’m sure I could’ve used the autoloader from the Phix project but I didn’t feel like screwing around with it. The composer one works and it was easy to tell it to use Slim. Once I start creating the models that I will use for this application I will add their location to that file too.

With that out of the way, it came time to discuss how to actually organize this application. I have a templates directory for my Twig templates, which totally makes sense. But what to do with the index.php file that Slim relies on. Like any front-controller-driven application all our requests, after being folded and mutilated by a web server rewrite rule, go through index.php. In the sample Slim app they have something like this in their index.php file:

1
2
3
4
5

$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();

This might be all Kool and the Gang if you only have a bunch of really small actions. This app will be interacting with models a lot, and I’m positive that despite my best efforts to roll with a “fat models, skinny controllers” paradigm that some of those actions will end up being lots of code. Smashing all that stuff together in one file strikes me as an abomination against best coding practices. Ed told me how the FictiveKin folks are organizing their Slim apps, so I have created something similar to it.

All my routes are going to go into a routes directory and then I will specifically include the routes I want via require calls. One route per file and I will try and name them something sensible.

1
2
3
4
5
6
7
8
9

<?php

require './bootstrap.php';

// Load all our routes
require './routes/main.php';
require './routes/hello.php';

$app->run();

Inside each one of these files will be an app->get|post|whatever call

1
2
3
4
5

<?php

$app->get('/', function() {
  echo 'MAIN PAGE';
});

Yes, that default route sucks but getting the structure in place was more important to me than having something useful stubbed out.

I’m sure there is more than one way to organize a Slim application, but this is one that I think works best for me.

So I went and bought a good bundle of ebooks about Node and started going through the tutorial code. These two seemed like a good place to start: an introductory tutorial and then another book that leaps right into things with the aim of really giving you some hands-on work with Node.

The crowning glory of my early work is this bit of code from a tutorial that emits events and then allows you to react to them:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

var EventEmitter = require('events').EventEmitter;
var util = require('util');

var Ticker = function(){};

util.inherits(Ticker, EventEmitter);

Ticker.prototype.tick = function() {
    self = this;
    interval = setInterval(function() {
        self.emit('tick');
    }, 1000);
};

var myTicker = new Ticker();

myTicker.on('tick', function() {
    console.log('TICK');
});

myTicker.tick();

Now I realize that this code sample is something very trivial but I also think it shows what someone who has mostly worked in languages without callbacks is up against when they start using node.

As a PHP guy I am used to my code being executed pretty much in the order that you read it when looking at the source code: from top to bottom, with jumps out to other code as required but always returning to this flow.

Once you start getting into callbacks and other evented paradigms it becomes a lot more difficult to intuitively figure out what’s going on. Note that I said “intuitively” because I’m sure that to anyone past the beginner stage with Node would understand what is going on there.

There is a lot that looks familiar though. We have the importing of modules via require statements. I also think this a good point to mention the outstanding job that npm does in helping to manage dependencies. I used to think that the Ruby gems system was one that should be aspired to. If you’re going to ignore CPAN that is.

Then I create what I can only describe as an empty object, and then we say that our Ticket object is going to inherit whatever is in EventEmitter. Okay, so far so good in terms of familiar territory.

Next we have the block of code that lets us create a tick method for our overall Ticker object, and this is done with a callback. We have scoping issues to deal with (hence the self = this line) and we are creating something that will emit a ‘tick’ event once a second (1000ms). That looks a little weird if you’re not used to callbacks, and we even have an anonymous function inside an anonymous function.

After that we then grab a Ticker object, tell it that every time there is a ‘tick’ event detected we want to log TICK to the console. Finally, we tell it to run myTicker.tick() and then it goes on it’s way emitting TICK once a second.

That’s not such a mind bender once you break it down the way I did. But what about this type of thing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var fs = require('fs');

fs.open('./a.txt', 'a', function(err, fd) {
    var writeBuffer = new Buffer('7');
    var bufferOffset = 0;
    var bufferLength = writeBuffer.length;
    var filePosition = 10;

    fs.write(fd, writeBuffer, bufferOffset, bufferLength, filePosition, function(err, written) {
        if (err) {
            throw err;
        }

        console.log('wrote ' + written + ' bytes');
    });
});

We all know that it is easy to write spaghetti code in PHP because of the fact that it grew up on the web: it was a templating language with C library wrappers. Very easy to just mash everything together. I see the same sort of spaghetti possibilities there in Node, with the added bonus of callbacks being mixed in there to make certain things difficult.

I understand what I did there: I am opening a file and then writing to it. The way that I got to do it made me scratch my head. Writing to the file happens as a callback that is executed as a result of opening up the file for appending? Like I said before, that does not strike me as very intuitive for programmers coming to Node with a little understanding of Javascript and jQuery, which is probably most programmers’ introduction to anonymous functions.

But I do get it. You cannot get non-blocking IO without doing such gyrations but I am concerned that sufficiently large Node applications will be, to put it bluntly, a fucking nightmare to debug. Is this something that cannot be moved away from if you choose to write programs using tools that suppoort concurrency and/or evented concepts?

I’d love to hear what sort of best practices people are using in order to tame the potential for Node applications degenerating into spaghetti hell.

“Got it. I have no formal CS background, but I’m trying to learn enough to build (something). I know enough PHP to kind of, sort of get by but am trying to solidify my foundation. So if I’m being selfish, write a post to someone in my position who wants to not suck at building stuff.”

This is actually a great question. Although the self-centered answer is to start off by buying my book, that isn’t really the question that is being asked.

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

I have spoken at length about my opinion that PHP won the web war because it was so tightly coupled with HTML and very early on had support to run with Apache via mod_php. However the world has changed, and the web war itself has changed. I think I can say with a smirk that the web war is now an asymmetrical one, where the expectations of behaviour by users is totally different.

But PHP is still in a really good position because of its true nature: PHP is glue. It’s glue that binds things together in a way to quickly produce HTML output. There is a reason the LAMP stack (with PHP as the “P”) was so successful: if you had to get data out of a database and onto an HTML page there was no easier way.

One of the trends that I see in PHP is that the frameworks that sit on top of PHP are starting to ask for influence over the development and direction of PHP itself. I have mixed feelings about this. On the one hand, it is good that people push for newer features in their chosen programming language. I think the PHP core is not necessarily against these suggestions but they move at different pace than the framework people. But my other concern is that we don’t end up with a framework driving the language.

When you think of Ruby, unless you are in denial or a really old Ruby hacker, you think of Rails. Without Rails Ruby does not get the push that it did and continues to get. It’s a good language but it would’ve languished in obscurity if not for DHH.

So what does this have to do with not sucking at building stuff in PHP? I think it’s important to understand that you can build cool stuff without relying on a framework. Heresy, I know. But if you keep thinking of PHP as glue it totally makes sense. How many applications are REALLY just PHP? They are really web server + data source + Javascript + CSS + HTML. Think about that for a minute. PHP is the glue that binds all that together.

The danger for people like Travis who are starting out with PHP is that they will get caught up with a mindset that a framework is the solution to their problems. It is one solution to the problem of building a web application, but failing to understand how to write PHP that behaves like glue will lead to a lot of problems later. Because when the time comes for you to do something that the framework did not anticipate you will be fucked. And you will be incorrect when you blame the framework.

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together. NoSQL data sources. Distributed workers. Queuing systems. Real-time document searching capabilities. These are all things that are NOT written in PHP but it is extremely likely that someone has written a library in PHP that can talk to them.

Hope that helps you Travis!

From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always “no, and if you do solve it please let met know how you fixed it.” Today, my friends, was the day.

Kudos to Damian Katz for coming up with a solution. Without digging deeper into it, I would imagine that you could alter the phpunit.xml file (if you are using one in your setup) to automatically use the -dzend.enable_gc=0 option every time you run a test.

How did he figure it out? He tracked down this bug that seemed to be displaying the exact behaviour that I had reported way back when. It seems odd that garbage collection would cause this problem, but perhaps it was a perfect storm of lots of small tests causing over-active garbage collection which in turn causes the PHP interpreter to abort whatever it is running.

This is another case where I would love someone with knowledge of PHP internals to try and explain why it is happening.

For me, this is somewhat uncomfortable. It is only natural that people who use certain tools tend to flock together at a conference. I joked that where were only 3.7 PHP developers (with someone stating that the 0.3 part is part of someone that I cut off for not writing tests) but the fact was that unless you knew members of multiple communities you were going to have to be content to feel a little excluded.

Anyway, I did have a really good time hanging out with my friends and making some new ones. It’s a really good idea to talk to as many people as you can, even they are not using the same tools you are using. You can gain some perspective.

Let’s go over the talks I attended and my thoughts on them.

It’s the Little Things (Brad Colbow)

Brad is a freelance graphic designer from the Cleveland area. He also does an online comic called The Brads so, as expected, his presentation was full of all sorts of awesome visuals. Also, I thought that I talked fast, this guy made me look like one of the Ents from Lord of The Rings.

The main take-away I got from his talk was that it never hurts to pay attention to the little things. I realized that this holds true from both an UI/UX perspective and in your code. A bunch of bad little things always turn out into one huge bad thing.

His slides describing the blog posting he made about how crazy it was to check out an audio book from his local library were awesome.

Vagrant: Virtualized Environments Made Simple (Matt Stine)

Matt took what he said was normally a 3 hour tutorial and crammed it into a very informative 1 hour talk. It did help that I had been considering the use of Vagrant anyway, but I got a better picture of more practical uses of Vagrant. I did not know about veewee as a tool to help you create your own Vagrant boxes.

This is of interest because I had a hankering to play around with an Arch Linux VM but found the existing base boxes out there, well, not working with the version of Virtualbox I had installed. I think veewee will let me pursue that further.

Breaking the Sound Barrier with Node.js on Windows and Azure (Glenn Block)

While sitting in this talk I took a picture and tweeted about how it was time to make myself “personally uncomfortable” by sitting in a talk involving a technology that I don’t use running on a platform I don’t use. What I was hoping to find out was some more basic information on Node.js and why it is such a big deal.

To be perfectly honest, the more I see Node.js the more I start to understand the allure of it. What really bothers me is that so many people are gambling their applications on a tool that hasn’t even reached 1.0 yet. I understand the power of how Node.js gets things done. Evented + concurrency + JS is a platform that has lots of appeal to people who maybe haven’t done that sort of work before. Not that I’m including myself in the group that “gets it” but at this point in time I’m still on the “I will use Twisted/Tornado if I need to create event-driven, high-concurrency web servers.”

Maybe when Node.js gets to 1.0 I will think differently.

Azure itself didn’t really thrill me that much, but I do see the advantage of that environment to people who have already made a large investment on the server side in Microsoft. What is really admirable is that they are making some great contributions back to the open source community. The SDK for running Node.js on Windows is open source, and I must give them credit for that.

Code Kata and Analysis (Jim Weirich)

This was a talk that I went into expecting to be surrounding by Ruby hipsterism. After all, this is the guy who created Rake and works for a well-known Ruby consultancy. Once I saw him I knew I was in for a treat. Older guy. White hair. Unix-style beard. Runs emacs.

I was not disappointed.

A code kata is a programming exercise that serves a few purposes. You do it in order to learn how to implement common algorithms in different languages and learn how to solve the easy problems by habit, with the goal of then freeing up your mind to solve hard problems.

The code kata this time was to create an arabic number to Roman numerals converter. The language of choice was Ruby (no big surprise there) and I was even happier to see that it was a test-driven kata using Rspec.

This brings me around to a topic that makes me super uncomfortable. It seems to me that testing has become an integral part of the Ruby and Python ecosystems. It does not appear to be common at all in the PHP and .NET communities. I care about this sort of stuff so it does pain me to see such opposition in the form of apathy and excuses amongst PHP programmers. I wish I could surround myself with developers who feel like I do about the value of automated testing in delivering solid applications. Maybe in the next life.

It was also good to see someone walk you through the whole TDD practice and refactor stuff after getting a particular set of tests working. In the end we had two great examples of code: an easy-to-understand converter and tests that are easy to understand.

Dealing with Information Overload (Scott Hanselman)

One of the more dynamic speakers I saw, Scott gave a talk to a packed room on tips for dealing with information overload. From him I learned some new techniques I’m going to be phasing in:

• No reading email until noon, and then “office hours” from a certain time onwards when anyone can speak to you
• Instapaper is awesome because I can flag things to read later and get them delivered to my Kindle on Friday afternoons for some after-dinner reading
• If this, then that is an extremely interesting tool that can be used to trigger events that help you delegate things into the future
• The Pomodoro Technique is a very useful tool to help with short-term focus. Cut out the distractions and concentrate for 25 minutes. Even I think I can do that.
• Keep your email responses very short (he reccomends Five Sentences) and instead write a longer response to that issue and post it somewhere others can find it, whether it is a company wiki or on your own blog. That way, next time someone asks you that same question you can point them there

Excellent talk full of lots of excellent ideas. I knew it was gonna be awesome when he put this video up to entertain us before his talk.

A Few of My Favorite [Python] Things (Mike Pirnat)

Mike is a long-time Python programmer who shared with us a “series of lightning talks crammed into one presentation”. While I have some basic Python knowledge I did see a bunch of really interesting libraries and other tools that I did not know about. He covered so much, so fast that I was glad he was going to post a link to the slides on his blog.

It also reminded me how, coming from the PHP world, languages like Ruby and Python really are more terse. You might not think it matters (or even hate significant whitespace) but for some people the elegance that can be found in Ruby and Python code often makes it easier for others to understand what you are doing. I know that I feel like I’m doing more with less when I write Python code.

Then I gave my own talk. I was disappointed that I actually ran out of time(!) for it. In the scheme of things, 90 slides is about 20 too many for a talk on as dense a topic as unit testing tools, strategies for writing code, and complementary tools to make the whole thing easier.

I have identified abotu 20 slides that I think I could chop out and turn into 2 slides of the “and if you’re interested in some tools that I think are helpful” type.

I had a good time (including hanging out at the Kalahari’s water park with my kids) at CodeMash 2012 and hope to go back for CodeMash 2013.

Why so little PHP?

I was asked about why I felt that there were so few talks about PHP and what could be done to make it better. Well, when only 7 people even submit PHP ideas I think there is a problem of visibility.

Given that this conference covers a wide variety of technologies I think it is safe to say that there was quite a bit of overlap. 31 .NET talks? Really? There is nothing wrong with .NET but do you really want to exclude an entire sector of the web programming world at your conference?

Also, there is the issue of speaker reimbursement I know that the official policy of CodeMash is “we cannot guarantee speaker reimbursement”. That’s cool but that will also stop talented people who are not willing to travel from where they are to the Cleveland airport and then hitch a ride to the Kalahari. Maybe in the PHP world we have gotten spoiled by those who run conferences since they tend to cover a significant portion of the costs a speaker might incur to get there.

There is no easy answer to how to get more PHP people to submit talks and to attend the conference in general. It probably also doesn’t help that the conference sold 1200 tickets in 20 minutes, making it that much harder to get a ticket.

I’d love for more PHP folks to come to this conference and get their horizons expanded with a glimpse at what other communities, just as full of energetic people but with different focusses, are doing.

I’ve been playing around with Sublime Text (because of the awesome vim bindings) and was thinking about why do I always have to be logged into the remote server to do my work. Normally I connect using SSH, then attach to my tmux session and then fire up vim.

This is okay but it lacks a certain elegance in it’s approach. As a result I end up using things like Dropbox to synchronize my .vimrc file so I get a consistent experience across environments. That’s ok for now, although I’m having some weirdness due to vim 7.2 vs. vim 7.3 issues in one of those environments.

I also need to be able to use git to commit changes, create and merge branches, etc. I need to be connected to the server to make that happen. But that is starting to feel like a limitation to me.

What I’m chafing against is having to deal with multiple environments all the time to get my work done. I want to use ONE editor, tweaked out exactly the way I want to edit code in multiple locations. I want to use ONE tool for handling git work in multiple locations.

Any thoughts on how to achieve what I want? There are occasions when I do need to connect to a server (say to tail a log while testing a Gearman job) but damnit it’s the second decade of the 21st century. This should be a SOLVABLE problem.

So for now I’m trying out SublimeText2 as my main editor and started using Transmit (sorry Expandrive but I am finding Transmit to be a lot more responsive) so the missing piece if for me to be able to commit code changes on a remote server WITHOUT being logged into that remote server.

In a perfect world I am using virtual machines for my dev work, but I haven’t convinced our awesome sysadmin to put in the time necessary to make it happen for me.

Let me know potential solutions for my desired setup.

It didn’t turn out to be The Great Canadian Novel but I did collect my thoughts on what goes into building PHP applications in such a way that they are easily testable. I called it “The Grumpy Programmer’s Guide To Building Testable PHP Applications”.

When I wrote my first book I did everything in Pages but that was before the rise of e-readers. This time I wanted to offer my book in PDF, epub and mobi formats. So I started up using AsciiDoc since I felt it gave me the most options for converting the text into other formats with a little bit of programming work. I created a Makefile (old school, baby!) that took the text and turned it into a PDF.

I had thought about doing the book directly in Docbook as it provided the best way for conversion purposes, but I found all the XML to be getting in the way of, you know, actually writing the thing. Plain text with a little bit of mark-up seemed to be the best fit for my brain.

As my self-imposed deadline got closer I felt like I was in for a lot of late nights fiddling around with layouts to get things to an acceptable level. Lucky for me an alternative came along.

I follow Reg Braithwaite (better known as @raganwald) and saw that he had a new ebook out called “What I’ve Learned From Failure” which he published with some help from Leanpub. The system looked awesome: write your book in Markdown (which I already use for this blog) and then it would create ebooks in PDF/epub/mobi for you, handling all the distribution and payment collection for you. Holy fuck, this is what I wanted.

So I took the plunge and signed up for an account. I started tweaking my text to use the Markdown-specific formats the system requires and little by little the book is being massaged into it’s new shape.

I’ve gotten some great feedback from my technical reviewers and will be incorporating those changes into the book as soon as I’ve converted it over to the Leanpub structure. I’m giving a talk on the topic the book covers at Codemash 2012 and will launch the book while I’m there, offering those who attend my talk a discount as a way of thanking them for travelling to the shores of Lake Erie in the middle of winter.

So please visit the home of my book online and until the book is published feel free to add your name to the mailing list. As soon as it’s available you will be notified. I’m still tweaking the pricing so feel free to suggest to me how much you’d be willing to pay for such a beast. It will probably come in between 40 and 50 pages in length.

(If you care the league uses a game that it creates itself using freely-available data from Retrosheet and if you’ve ever come across Strat-O-Matic-Baseball you might have an idea of how game-play works)

I’ve had middling success in that league: some really crappy seasons where I clearly did not know what I was doing along with making the playoffs 3 years out of 4 complete with a trip to our league champsionship series. Many times I’ve had teams where the skills of the players (who are merely statistical representations within the confines of the game rules) simply aren’t a good fit.

If you have lots of power, a good bullpen, but guys who don’t get on-base you will find yourself winning by a lot or losing by a lot because power comes and goes. If you have great pitching but a bad offense (similar to what I have for our upcoming 2012 season) then you will find yourself in many close games but you will probably lose more of them than you win because your offense will be unable to come through when needed.

I’ve also learned that I am a decent field manager (in terms of playing the games and understanding strategies), lousy at evaluating hitters in our draft (my past 4 first-round picks have been hitters who have been injured and/or underachieved), great at evaluating pitchers, and very impatient in the trade market when trying to improve my team.

I went through a terrible season last year due to a combination of bad luck and impatience in making trades to keep a fringe playoff contender in the playoff hunt in 2010, then crashing to lose almost 120 games in 2011. So I struggle to find ways to build a better team, and better identify the combination of skills I need for my team to achieve success.

So what does all this have to do with programming? I feel that my current set of skills are a terrible match for today’s programming environment and it’s making me feel a set of emotions I thought I ditched when I left high school: jealousy, fear, angst and regret.

I’ve always prided myself in thinking that I have spotted trends in programming before everyone else. I first saw the value of frameworks in 2003-2004. About the same time I discovered SimpleTest and thought that it would be a very valuable tool. It’s almost 2012 and I still feel the same way, but I feel like the programming community I belong to still doesn’t give a shit.

In February of this year I jumped on an opportunity to work with some people I respect in the PHP community and joined Moontoast. It had been a while since I had done the startup thing and thought it would be a good change for me. At my previous employer I had to do everything myself for my projects and I looked at Moontoast as an opportunity to work with a team again.

Instead I struggled. Struggled to cope with two applications written using heavily-modified versions of two frameworks. Struggled to understand the business that relied on these applications. Struggled with the idea that the things I felt really, REALLY mattered simply don’t matter to the business as a whole. It’s not a lie when I say it hurt. Hurt a lot to miss deadlines and let down team members. Hurt a lot to struggle to make things like automated testing and simpler product development FUCKING WORK and not achieve anything. Struggled while wondering if I was getting honest feedback from fellow employees who might not want to really say what they feel because they are not an asshole like I often am.

On top of that, I felt like the volume of tweets and blog posts I cranked out achieved nothing that I could hang my hat on and make my ego stop screaming at me in my head. I still care immensely about best practices, automation, and building applications that can be easily tested. All too often I feel like I am the only one who wants it so bad I pound my fists on my desk like a little boy having a fucking temper tantrum.

The feedback loop I want just isn’t there any more. Perhaps my troll-like existence in my home office is wearing me down and making it more difficult for me to actually get along with people. My ego is getting in the way of success in a team setting and I am struggling to find a way to figure out how to change things for the better.

PHP is the tool I’ve been using pretty much non-stop since 1998. It won the web battle. It really did. But things are changing and expectations are changing amongst the next wave of programmers. Elegance in code matters. Ability to support concurrency at the code level matters. Perhaps it shouldn’t but it does. I think of all the investment I’ve made in PHP and I find myself constantly asking the question “did you do the right thing?”

I have found that the PHP community is very supportive of me and my ideas, so I’m probably not as terrible a person as I make myself out to be. But the PHP community as a whole really seems to think that much of the stuff I consider to be important is just a waste of time, getting in the way of getting things done so you can go home after work.

The crowd I follow online is a self-selecting one. Most of them care about the same things (except there are those who disagree with me on the importance of automated testing as a critical part of development) but what about those who aren’t there? How many of them give a shit about clear, concise code? How many of them have actually created an application for their employer that had a complete testing suite (in 14 years I’ve been able to do that ONCE) for it? How many of them have automated their deployments as a result of a merge of code in their version control system?

It’s more likely that I am being selfish and demanding recognition for the things I’ve done and don’t really deserve that recognition. I joke with my wife that I am a “big deal on the Internet” and #internetfamous on Twitter, but am I really? Or am I just loud and repeat myself over and over again. Am I just being tolerated or are there people for whom my thoughts are resonating and they are going out and kicking ass in a way I have been unable to?

Maybe this old saying is true: those who can, do, and those who can’t, teach.

2011 was the year of the struggle for me. I don’t want 2012 to be like that but I am not sure how because I’m scared that I’m becoming useless and irrelevant and that the things I am passionate about have no place in the modern PHP community, the only one I’ve ever really been a part of.

Hope you have a good 2012. I’ll be here, struggling.

Now even though it is just us complaining about stuff in PHP that we don’t like, regardless of the true merits of our complaints, it sparked a discussion on Twitter about just what should be done to make handling PUT and DELETE requests better in PHP.

$_POST and $_GET are workhorses of the PHP world, used in any application that accepts web requests from somewhere. Sometimes accessing them is wrapped inside objects or filtered out using the filter() extension of even Inspekt but I think this illustrates the problem.

Laura Thompson made the suggestion that PHP should look to port the concept of the Request object that Python uses over to PHP. As a cryptopythonista I think that is an excellent idea. Elizabeth Smith did ask for some constructive ideas on solving this problem. While my C skills are non-existent, I thought I’d delve a bit into more higher-level thoughts about this.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

What I’m really after is for an easy way to detect that a PUT or DELETE request has been made. Existing solutions for these are not pretty and ( in my opinion) non-intuitive. With my thoughts that PHP is quickly turning into a tool used for web service API end points that don’t require insane levels of concurrency, the idea that there is no native support for figuring out if you’re been given a PUT or DELETE request is disheartening.

The PECL HTTP extension is a step in the correct direction, but it too has some rough edges and would require a lot of polishing before it could be moved into the core where it really belongs.

Again, what I’m looking for is an easy way for PHP to be able to know what type of request it is dealing with so I can make my PHP applications more aware of what it being asked of them. It seems that pretty much every framework implements their own Request/Response objects, so that should be an indication that this kind of code abstraction is a desired core PHP feature.

Share your thoughts with me in the comments.