Stickler CI users have expressed that automatically enabling default linters can create a flood unwanted comments in pull requests, which is overwhelming and noisy. In response to these issues, we have changed the process of connecting a repository to Stickler CI.

Integration testing with external webservices, has historically been an uncomforable process in PHP for me. It frequently involves complicated mocking that was fragile and hard to maintain. I’ve long wished for a PHP library that was as simple to use as HTTPretty is in Python.

I’d like to introduce a project I’ve been working on over the past few months. Stickler-CI helps automate the tedious process of ensuring coding standards are followed during pull requests. Like many teams, FreshBooks uses pull requests as a way to solicit feedback from other developers, ensure consistent coding practices and catch bugs before they can cause real problems.

The events system has become an integral part of CakePHP since its introduction in 2.1. When originally introduced, we needed to make a number of compromises in the implementation to facilitate compatibility with the code it was replacing. For 3.0, I wanted to revisit the event subsystem and try to make things more efficient and streamline the API a bit.

I try to keep fairly busy. Between work, being a dad, and working on existing open source projects, I found time to work on two new ones.

Xhgui2

Profiling is a very interesting topic for me. I love spending time sifting through results trying to find ways to make code run faster or use less memory. XHProf is a C-extension created by Facebook.

Making sure your freshly released CakePHP plugin still passes all of its tests can be a bit of a time sink. Setting up Jenkins for small project can be a big job. After I setup Jenkins once or twice, I personally longed for a simple way to get continuous integration with not much work.

At work we’ve been using selenium webdriver to enable automated browser testing as part of our regression suite. One of the most difficult parts we’ve had is maintaining DOM synchronization.

In the last article I went over the various static analysis tools I’ve found useful, and how to get them installed. For this installment, I’ll be going over how to use make to run all the tasks, and how to configure all the tools to work with Jenkins.

I’ve recently integrated static analysis tools into both my day job’s and CakePHP’s development process. Setting up static analysis tools is reasonably easy and can help you find problems before you even get to unit tests, or staging sites. They are also the ideal tool to help enforce coding standards, and best practices that can be checked by reading the code.

We use selenium extensively at work for automated acceptance tests. If you’ve never used selenium, it allows you to record and playback browser sessions and create integration tests from the perspective of a browser. Its generally a great tool, and really helps make sure we don’t release broken code. Recently, however I’ve found Selenium can have adverse reactions with jQuery.

With the recent release of PHP 5.4-RC1, I wanted to give it a spin and make sure there weren’t any upcoming issues for CakePHP. I recently saw a great article from Derick Rethans on getting PHP setup from an SVN checkout.

I recently had a fun idea, that I wanted to try and implement for PHPUnit. I really like coloured console output. PHPUnit already has the option for coloured output, but I wanted more. I wanted to get coloured text for F, E, S, and I that showed up in the test run progress.

Previously I wrote about the changes that have been done for the request handling in CakePHP 2.0. Response handling is another subsystem that has received a significant facelift. As with request information and functionality, response related features were spread across several objects. Controller, RequestHandler and Dispatcher all had a slice of the pie.

As you may or may not know CakePHP is transitioning to PHPUnit and with this transition comes a totally new Mock object interface/implementation.

In the recent bakery article concerning the ongoing development of CakePHP 2.0. The already underway migration from SimpleTest to PHPUnit was introduced. I wanted to go into some of the reasons and motivations for that decision as well as explain some of the long term benefits.

Shells are one of the more difficult objects to properly unit test. Since they normally run in a CLI context instead of a web context they provide some interesting challenges. The biggest hurdles are separating the Shell from the CLI environment, and simulating the correct arguments and parameters.

So originally when I built this site, I was in the “requestAction is bad” camp. So much so that I created a convoluted Component to assist in the creation of the sideboxes featured on this site. A sample of that code is as follows:

I spend a lot of time in various IRC channels answering questions and helping out, and one recurring theme that pops up again and again is people not knowing what to do when things go wrong. Whether it be a simple error or a logical mixup, people often lack the tools or processes to figure things out. So I thought I would share how I approach errors and problems.

In the ongoing struggle against code bloat and creative ways to do things, I’ve been playing with throwing exceptions from model methods. While not earth shattering stuff, I’ve found it to have a few advantages over returning false. First, you can end up with less if and else statements.