News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Theo Kouzelis:
Improving Readability of PHPUnit Data Providers
April 10, 2015 @ 12:01:28

Theo Kouzelis has a recent tutorial posted showing you how to make your PHPUnit tests a bit cleaner with the help of data providers, a built-in tool for PHPUnit that allows for easier validation of larger datasets.

When writing tests I try to describe the test in the function name. I use the format testDoesSomethingWhenPassedSomething to first describe the assertion and then the context. [...] When I have many data sets running against the same test I will use the frameworks data providers to make the code less verbose.

He includes code examples to show both the difference between the single data tests and one using a set of email addresses to validate their correctness. He notes that the error message using data providers can be confusing (and maybe hide the real problem) so he offers a solution to make it more readable: associative arrays. The trick is that PHPUnit uses the key to display the error and by making this unique you can make the error output more informative.

0 comments voice your opinion now!
dataprovider tutorial readability phpunit unittest associative array


Stephan Hochdörfer:
Running PHPUnit via Phing on HHVM
February 26, 2015 @ 09:16:58

Stephan Hochdörfer has a quick post showing how he has PHPunit up and working on an HHVM instance. His problem was that the tests were actually executing using the "php" binary, not the HHVM one.

For quite some time we run the unit tests for our libs and tools against PHP and HHVM, at least that is what I thought up to now. As it turns out I missed a minor detail. [...] What happens now is that Phing is executed via HHVM but PHPUnit will still be executed via the PHP binary because the PHPUnit shell script will look for the php binary in the PATH configuration. Since we run HHVM side-by-side with PHP on our Jenkins build nodes I was not able to point /usr/bin/php to /usr/bin/hhvm - which would be the easiest and cleanest solution. I

He shares the workaround he created, creating a symbolic link between the hhvm and php binaries and then executing the Phing task to run the tests. This is being run via Jenkins and uses it's "WORKSPACE" as a container so the main "php" binary isn't overwritten.

0 comments voice your opinion now!
hhvm phpunit test unittest execute binary path jenkins phing task


SitePoint PHP Blog:
Testing APIs with RAML
February 24, 2015 @ 10:19:39

The SitePoint PHP blog has a new tutorial posted today showing you how to test your API via RAML, using the structure it defines to verify the requests and responses made to the API. This is the second part of the series and you can find part one (the introduction to RAML) here.

In a recent article I looked at RESTful API Modeling Language (RAML). I provided an overview of what RAML is all about, how to write it and some of its uses. This time, I'm going to look at some of the ways in which you can use RAML for testing. We'll start by using RAML to validate responses from an API. Then we'll look at an approach you could take to mock an API server, using a RAML file to create mock HTTP responses.

He starts off by defining a basic RAML document that defines an "Albums" structure with endpoints for "account" and "albums" with various data beneath each one (and created an application that follows it). He then shows how to combine Guzzle, PHPUnit and a RAML parser to grab the API definition and set up a sample test. A simple example test is provided showing you how to check the validity of a response structure. Then he gets into mocking the API using the RAML structure using the FastRoute router. He creates a mock object and a "dispatch" method to handle the request routing based on the contents of the RAML document. He also includes a method to check the parameter values on a request, ensuring they're the correct types.

0 comments voice your opinion now!
tutorial testing unittest phpunit raml api documentation mock fastroute

PHPUnit 4.5 and Prophecy
February 06, 2015 @ 13:56:21

On blog today Sebastian Bergmann has posted about the new release of PHPUnit (4.5) and how it now comes with support for the Prophecy mocking tool.

PHPUnit has had built-in support for creating test doubles for many years. This implementation was originally inspired by the first generation of mocking frameworks for Java. Since then mocking frameworks have evolved. Modern mocking frameworks are more intuitive to use, lead to more readable code, and may even allow for a clear separation of a test double's configuration and the actual test double object itself.

Like many users of PHPUnit I am not satisfied with the API of PHPUnit's own mocking framework. This dissatisfaction has lead to the development of alternative mocking frameworks for PHP such as Mockery, Phake, or Prophecy. If I were to create a new mocking framework today it would probably look a lot like Prophecy. Which is why PHPUnit 4.5 introduced out-of-the-box support for it.

He gets into some of the basics of the Prophecy tool and how it handles mocking differently than the current internal mocking PHPUnit provides. Some code examples are included showing dummies, stubs and mocks with an example of the output when some of the "predictions" have failed.

0 comments voice your opinion now!
phpunit version upgrade prophecy mock dummy stub framework

PHPUnit Migration from PEAR to PHAR
January 14, 2015 @ 13:48:34

On The PHPcc's site today Sebastian Bergmann, the creator of the popular PHPUnit unit testing framework, shows you how to move to using the tool's phar file and away from the previously used PEAR install method.

In April 2014 I announced that I would shut down on December 31, 2014. The motivation behind this move was to simplify the release process of PHPUnit by getting rid of an outdated distribution channel. I was afraid that I would leave users of my software behind by this move. [...] I am relieved that the shutdown of went as smooth as it did. [...] In this article I show you how to make the transition from using PHPUnit from a PEAR package to using PHPUnit from a PHP Archive or using Composer as easy and convenient as possible.

There's three main steps to the migration from PEAR to the Composer-based phar installation:

  • Uninstalling PEAR Packages
  • Using PHPUnit from a PHP Archive (PHAR)
  • Installing PHPUnit with Composer

He includes the commands and configuration files/settings you'll need to make the transition happen. He also mentions that older versions are still available if there's a need but only on GitHub/Packagist as phar packages, not via PEAR.

0 comments voice your opinion now!
phpunit migration pear phar packagist composer tutorial


Derick Rethans:
Code Coverage Finding Paths
January 07, 2015 @ 09:33:13

Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

0 comments voice your opinion now!
code coverage phpunit xdebug report paths vld lines


Robert Basic:
Mocking hard dependencies with Mockery
December 26, 2014 @ 11:14:51

Robert Basic has a post today showing how you can mock hard dependencies with Mockery, a mocking library for use in unit testing. In this case, "hard" refers to work around the use of "new" creating objects in hard to test places.

One problem with unit testing legacy applications is that the code has new statements all over the place, instantiating new objects in a way that doesn't really makes it easier to test the code. Of course, the easy answer to this is "Just refactor your application!", but that's almost always easier said than done. If refactoring is an option, do it. If not, one option is to use Mockery to mock the hard dependencies.

He makes use of instance mocks to show the overloading of the service without the need for a refactor. This overrides it on a more global scale, so it could have an effect on other tests. He shows how autoloading and PHPUnit's own process isolation handling can fix tis problem (though it takes more time to run the tests this way). He includes sample code of the whole process so you can easily follow along too.

0 comments voice your opinion now!
mockery dependency hard new instance phpunit unittest


Derick Rethans:
Code Coverage The Present
December 02, 2014 @ 11:54:01

Derick Rethans has posted the first in a series focusing on the Xdebug tool and the code coverage functionality it can provide via PHPUnit's testing. In this first post he catches the reader up on the current state of things and what all the Xdebug tool can do.

Since ages Xdebug has provided code coverage support for PHPUnit, a way to show which lines are covered by your test cases. But I never really wrote about how it works. A recently filed bug prompted me to write this post, as well as a follow up post on Code Coverage's future.

He starts off with the early days of Xdebug, how it hooked into the Zend Engine (that powers a lot of PHP behind the scenes) and when it was triggered. This came with its own set of problems so Xdebug was updated to overload some opcodes. He talks about how it can calculate the unused lines and determines which lines can be covered in the code coverage results. He provides some example code showing the execution of the coverage report on a simple function and try/catch handler, complete with the HTML output of the results.

0 comments voice your opinion now!
xdebug codecoverage phpunit coverage history functionality opcode


Matthew Weier O'Phinney:
Testing Code That Emits Output
August 25, 2014 @ 09:45:08

In this latest post to his site Matthew Weier O'Phinney gives his suggestion on how to test (unit test) code that provides some kind of direct output. In his case, his script is outputting header information directly, not as a part of a response string.

Here's the scenario: you have code that will emit headers and content, for instance, a front controller. How do you test this? The answer is remarkably simple, but non-obvious: namespaces.

He talks some about the use of namespaces in PHP classes (and methods, and constants...) and how things can be importing using them. He gives an example of an object that outputs some header and body information (an "Output" abstract class). He shows how to use the class in a simple test, calling "reset" in the setup and teardown methods and asserting the contents of the headers and body for expected content.

0 comments voice your opinion now!
test unittest code phpunit output direct namespace tutorial


Giorgio Sironi:
PHPUnit Essentials review
August 18, 2014 @ 11:52:00

Giorgio Sironi has posted a quick book review of a recent publication from Packt Publishing: "PHPUnit Essentials". The author, Zdenek Machek, has written a "practical guide featuring a step-by-step approach that aims to help PHP developers who want to learn or improve their software testing skills."

The first thing that struck me about the book was the breadth of subjects: you start from mocks and command line options, to get even to Selenium usage. [...] There is a bit of what may seem outdated information in the book such as how to perform a PEAR-based installation, but it's identified as such (PEAR being deprecated and dismissed by the end of the year.) Another seemingly outdated tool is Selenium IDE, but once upgraded with a formatter for Selenium2TestCase like explained in this book it becomes usable again. This kind of advice demonstrates the real world experience of the author and makes you trust the content.

He suggest that the book is more for those just starting out on their testing journey and wanting to get up to speed quickly with a wide range of tools, not just the base PHPUnit handling.

0 comments voice your opinion now!
phpunit essentials review bookreview introduction


Community Events

Don't see your event here?
Let us know!

framework introduction api interview podcast release example version library language extension php7 laravel laravel5 community conference voicesoftheelephpant opinion series unittest

All content copyright, 2015 :: - Powered by the Solar PHP Framework