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.

This is guest post by Ragazzo. He uses Behat as well as Codeception for making his project better. He was often asked to do a comparison between Codeception, Behat, and PhpUnit. In this post he explains the commons and different parts of this products.

The author talks some about the difference between functional/acceptance tests and how they fit in with behavior driven development. He includes some examples of Behat test formats (Gherkin) and how it can be used for both the functional and acceptance side of things. He also talks some about why he prefers Codeception over Behat(+Mink) for his testing. A sample Codeception test is included, showing a login form check.

Automated testing is big news these days. There's hardly a PHP conference happening without a talk on testing automation or derivative methodologies. TDD (Test-Driven Development) and BDD (Behaviour Driven Development) are all around us. So why should you care about all this? [...] The more complex an application becomes, the harder it is to be sure that each new feature or bug fix won't break the system, and that decreases your overall confidence in your work as developer. That's exactly the reason why you need automated testing - to be confident that you're not breaking important parts of an application.

For his examples he uses a simple Silex-based application (found here on github) that just shows a main page and an "add article" page that returns a preview when submitted. He shows how to get Behat/Mink installed and how to bootstrap PHPUnit to allow you to execute your tests. Also included is a sample test that clicks the "Add Article" link, runs a few checks and fills in some data. The form is submitted and the "preview" page is checked for valid results.

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.

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.

Previously in my PHPUnit tutorial series, you learned about the very powerful concept of mock objects and stub methods. This concept is central to successful unit testing, and once it fully 'clicks' in your head you will start to realize how useful and simple testing can be. There is also another thing I want to make clear: creating tests is basically a puzzle - you simply have to go step by step, making sure all the pieces fit together correctly so you can get your green. I hope to make clear what I mean by the end of this tutorial.

He assumes you already know about mock objects and introduces the concept of "stub methods" and "mock methods", noting the difference between them. He then gets into what he calls the "four pathways of getMockBuilder" and talks about the rationale behind mocking methods in the first place. He then gets into constructors and how you can work around the "bad" ones with help from mock object functionality.

If you're interested in reading the rest of the series, you can find links to them here.

In our action-packed 30th episode Ed and Chris discussed their experiences with JavaScript testing tools, specifically how certain tools push you towards specific refactoring patterns. Chris talked about the successful launch of his latest book on using PHPUnit and got into some honest talk about revenue and how the product development course helped him make this book do 4 times the launch day revenue of his previous one. Ed discussed his plans to talk about mental illness on the conference circuit this year. Please help out by donating to the campaign!

You can listen to this latest episode either using the downloading the mp3. You can also subscribe to the feed to get this and future episodes as they're released.

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.

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.

You know you need something better, but time just doesn't seem to be on your side. Making things "right" is costly and you need to deliver working code NOW. Tests would be great but there are real deadlines to meet. You can't stop development and churn away for hours just to add tests around what you know already works. [...] No longer would you dread the bug reports. You'd happily make changes knowing that your safety net is there. You'd try out new features guiding yourself with tests.

The book covers some more advanced topics than you might have seen in the previous book including data providers, test doubles, faking test data (or using external sources) and writing tests for APIs, databases and exceptions. If this sounds interesting to you, you can pick up your own copy of the book on his site (or try out the sample first).