Our friends Ed Finkler and Chris Hartjes recently had a chat about testing in PHP. Read on to get the low down on different testing tools and their relative merits-check it out as Ed and Chris weep for the future, come to some interesting conclusions and get their hands dirty so you don't have to.

They talk some about the current tools for unit testing in PHP applications and show what a sample test looks like. Ed talks about how the current testing tools can make it intimidating for people to get started testing and mentions the built-in testing library in Python that is a bit easier. There's also some mention of acceptance/functional testing and the Behat + Mink combo.

While Composer has been around for a while now, many packages are still in their infancy (< 1.0) or sometimes are just not as feature filled as they could be. To be fair there is always more to be done. It can always do more, or do the same thing more efficiently. Whatever the case, pull requests are going to be a common thing for the PHP community to be doing to these packages and this needs to be done safely, with unit-testing. So, how do you run their test suite and add your own tests?

He includes a step-by-step guide to getting the environment set up to run the package's tests and how to add some of your own. He includes the commands to send the pull request back up to Github (on your own fork, of course) and how to use that same fork as your package resource until the main project is updated.

As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I'm using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.

In this blog post I want to show you a very simple technique for using RabbitMQ in our Unit or Functional Tests. Let's say you wrote a bunch of tests for your RabbitMQ consumers and then it's time to run them. To do that you probably need to setup a RabbitMQ server just for tests with their own users and passwords, or you need to set up a whole new virtual host for your tests. [...] With a future release of RabbitMQ that we can already test on the nightlies website, we can run RabbitMQ without the need to install Erlang. We created a package that ships a stripped down version of Erlang together with the broker bits, so running RabbitMQ now is as easy as downloading a tarball, uncompressing it and starting the server.

With a combination of this more self-contained package and some listener handling through PHPUnit, they uncompress the tarball with a PHP script and start the server with the defined configuration. Then, once the tests are done, it cleans itself up and removes the entire server directory to make for a clean run the next time.

Like many of us, despite being told repeatedly how great testing is, the benefits it will bring, the time it will save and how it will improve the quality of my applications, I too considered testing a second-thought. I saw it as something which was both expensive and time-consuming. If I was genuine with you, I'd say I believed it be be nothing more than a "nice to have", after the application was written. If you also feel (or have felt) this way - know that you're not alone.

He realized, though, that the usual false assumptions about testing were just that and starteed getting into testing, TDD and BDD on recent projects. He talks some about some general thoughts around testing like "testing can't be an after-thought" and the fact that it's no always easy. He includes a way of thinking about testing in your application and the confidence good, solid tests can bring.

Benjamin Eberlei introduced me to Phake with his recent article: it is a Composer-ready PHP library that integrates easily with PHPUnit and provides an independent Test Doubles framework, capable of producing Stubs, Mocks, and Spies. The syntax and object model reminds me of Mockito, the Java Test Double framework from the authors of Growing Object-Oriented Software. I like tools that do one thing and do it well, and after experimenting with Phake I'm using it on all new code.

He compares the two tools on a few different pieces of functionality including creating stubs, mocks and spies. Sample code is included for both sides. It's not a detailed guide by any means, but it can give you a better picture of how the two compare.

I look at the situation we have gotten into by having this problem [of replacing a large legacy application], and frankly, it is like the tech version of 'Scared Straight'. The paranoia of such a far reaching application within the enterprise that absolutely has to deploy successfully and also be very flexible to meet the needs of the future have driven me to the point of near madness in trying to make sure this thing is bulletproof, enter Test Driven Development.

He includes an example situation he recently was faced with in his code...and opted for the "easy" way out (difficult to test). He talks some about the issues, dependencies and coupled code this has created. He does, however, show a solution to the issue - passing in the dependencies as they're needed, not defining them in the method.

For me, writing custom apps in an enterprise environment is not about rapid deployment and looking like a hero. It is about deploying software with a design life of 7-10 years, because the change management involved in deployment is not something you want be be doing over and over again. Testable code with 100% coverage of unit tests, well developed integration testing, and prolific use of tools like PHPUnit & Selenium are part of the development culture because while speed is important, durability is even more critical to business.

When I state "as is", I truly mean the way it's being used in production. So the database call collects real data on which business logic is applied. You can see this is not a healthy situation, especially when you also have services that apply business logic on data and store it back into the database. In "Chris Hartjes wrote this one sentence that says it all: "Unit test suites are meant to be testing code, not the ability of a database server to return results". And he's right, you shouldn't use database connections when your testing business rules and functional logic.

He goes on to show a few code examples that show a pre-mocked state of testing where the Product information is pulled directly from a PDO connection. The more correct version mocks out this object, though, and overrides the "execute" and "fetchAll" methods to return mocked results.

The use of Mock and Stub Objects is an important skill to learn when using Test Driven Development (TDD). Mock objects allow you to replace dependencies of an object with lookalikes, much like crash test dummies are used during automobile safety tests so humans aren't harmed. [...] Using Mocks in PHPUnit tests means using the built-in MockObjects library for quite some years. In the last years two contenders emerged that can be used as optional dependencies in PHPUnit. [...] This blog post introduces Phake, because it works quite differently than both PHPUnit Mock Objects and Mockery.

They include a code example of how to create mocks with Phake, showing it's different approach to defining the mocked methods. They explain each part of the code, detailing the use of the "when", "thenReturn" and "verify" methods. You can find out more about Phake and see other examples in the project's documentation.

I've already written about my experiments with Paratest. Paratest is a PHPUnit wrapper that allows you to run tests written for PHPUnit in parallel, making us of multiple processes running on the same machine. In a world where cycle time is an important metric, trading resources to get the test suite to finish earlier is a net gain; especially when you're stepping on unstable stones and run the suite very often.

He (Giorgio Sironi) has contributed a new test runner to the project - the "WrapperRunner" that limits the number of processes spawned by the parallel testing tool. Another contribution came from Dimitris Baltas involving the addition of a TEST_TOKEN variable that can be used to uniquely identify each process as they're executing.