We recently upgraded phpunit from a very old version to the current 3.6.x version (at time of writing). During the upgrade I noticed that assertType is no longer supported in many of our tests which were testing if something was a string, an array, or an object. So I had to write a quick script to update assertType to assertInternalType and figured I would post it for others if they needed to do the same.

The code goes into each of your tests (recursively) and finds the places where the "assertType" assertion is used and replaces it with its newer cousin "assertIntrnalType".

So how does the Grumpy Programmer write code, TDD style? It starts with using a set of tools that reduce the amount of friction required. First, I do almost all my work from a terminal. [...] 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.

He also talks about his editor of choice, vim, and some of the plugins he uses in his day to day testing development. This includes tools to handle things like interfacing with git/gists, working with ctags to see the code's structure, working with "surroundings" and the pathogen plugin to make adding other plugins easier. He keeps the code up in one terminal and his testing tool (PHPUnit or other) accessible in a second, making it a simple matter of switching to write the test then the functionality to make it pass.

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.

As part of our release process for Zend Framework 1.12, I've been working through the unit tests and running them on PHP 5.2.4 as it seems that recent changes weren't being tested with that version. This isn't totally surprising as Open Source contributors are, almost by definition, interested in new things and so are much more likely to be running PHP 5.4 rather than 5.2!

Since there's a compatibility issue between the tests and the current versions of PHPUnit, he shows you how to install the 3.4 version instead following these instructions. Then, to run the tests, it's a simple call to execute this PHPUnit version with options for outputting to the "standard error", setting an infinite memory limit and pointing to the tests for your component of choice.

I'm trying to do some remote debugging with PHPUnit on a remote system. I was following the rules I had written about in a previous article but for some reason I could not get path mapping to work. So I figured I'd ping the Studio lead developer because as soon as I did that I'd get it to work. Well, that's what happened.

His fix comes in the form of setting a command-line parameter, QUERY_STRING, with the correct parameter order so the paths will get mapped back to the correct project. This parameter is a URL-encoded set of parameters that do things like start the debugging, set up the hostname for the debugger to point to and map the "original URL" back to your choice of values.

The legacy code dilemma, however, is always present: you can't refactor the code before putting up some tests on it to avoid regressions and putting your application offline. At the same time, you can't easily unit test the code until some refactoring is introduced.

He suggests making copies of some files to allow you to make small changes where needed to "mock" resources in the application to prevent it from accessing the actual data sources. His method fakes HTTP requests to the script and uses the copy of the script as an internal resource. Don't worry, code is included showing how its done - a basic "ForumPosting" class that includes the needed file and wraps the output in a buffer.

While PHPUnit is awesome out of the box, it still lacks some tools that are required to do things like test protected class methods or assign values to protected class attributes. Lucky for me we have an awesome testing engineer at Kaplan named Will Parker who has shown me some ways that they have extended PHPUnit itself to make testing certain things easier.

Chris talks about things like testing protected methods (easy thanks to a helper) and checking the value of a class property. The key to both of them lies in using PHP's own Reflection functionality to alter properties on the class objects themselves.

Last month, we had discussion about implementing page object pattern in Behat/Mink framework at London Behat Users meetup. Page object pattern is a cool way to make tests maintainable, reusable and readable. Everyone was interested to know more about Page Object Pattern. In this short tutorial, we will implement Mink and PHPUnit combination for functional testing. Mink and PHPUnit combined with Pageness (Page Object) can be used for maintainable and readable tests.

He assumes that you might not have all the tools needed installed, so he walks you through the setup/install of PHPUnit, the PHPUnit-Mink framework and both the Sahi and Selenium drivers. He includes a basic directory structure for the testing and shows how to create some Page Object classes that extend the default TestCase and make calling the remote resource simple. He also includes the steps needed to execute the tests via PHPUnit.

Testing web applications is not only based on unit and functional tests for the server-side (PHP, Java) and client-side (JavaScript) components, but also on end-to-end tests like the ones performed with Selenium. Selenium is capable of driving a real browser like Firefox in the same way a user would do, letting you express a test with a series of page to load, element selections, clicks and typed characters. [...] In this tutorial, we'll experiment with the Android Driver and set up a couple of tests to run inside an Android virtual device.

He walks you through the basic setup of an Android environment (based on the Android SDK) and how to start up the Android driver installed from the Selenium site. An example test is included, showing how to make a request for a test page and checking its title as well as checking that the input from the "keyboard" is successful.

In the realm of acceptance testing, a possibility for hooking into the application and exercising it end-to-end is to work through a user interface, which nowadays is in more and more cases web-based. The Page Object pattern is a way to model pages (intended as screens) of a web application as independent objects, and give them several responsibilities.

The pattern sets up the resources to let you make queries against the page's contents, interacting with elements on the page, running common assertions on the contents and moving around on the site. He gives a more practical example of it in action (again, using PHPUnit_Selenium) to test a login page and evaluate a successful login.

There's already a great article here that discusses Test Driven Development, but did you know that you can also test the code that interacts with your database? Especially if your application is data intensive, subjecting your CRUD code to a battery of tests is good practice that helps ensure that your application is working correctly. In this article you will be learning how to write database tests in PHP using PHPUnit and its database extension.

Included in the post is an example schema and an example of the seed data (defined as XML) for the testing to use as predictable data in its execution. His test class extends PHPUnit_Extensions_Database_TestCase (instead of the usual PHPUnit_Framework_TestCase) and a test for a basic "getArticles" method in his "IArticleDAO" class. By calling the "createXMLDataSet" method, the test loads in the pre-defined XML records and allows the correct evaluation of the assertions,