News Feed
Sections




News Archive
feed this:

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

Freek Lijten:
Testing and improving PHP extensions for PHP 7
March 13, 2015 @ 10:02:47

In his latest post Freek Lijten talks about PHP extensions, the upcoming PHP version - well, PHP7 - and the things that can be (and are being) done to help improve and prepare the extension ecosystem. In his post he walks you through the process of getting a PHP7 install set up, a sample extension set up and writing some tests to help improve it.

PHP7 is coming. And it is coming to a neighbourhood near you :) A couple of people started an initiative to ensure extensions will be running out of the box once PHP7 hits the shelves. The fun part: You can help too! No C knowledge is necessary (although it is fun to dive into PHP's internals!). This piece is a short intro to help you help PHP! Help triaging extensions, write tests, add documentation and who knows when you'll be diving into C code.

He's encouraging this work as a part of the recently launched GoPHP7 - Extensions initiative launched a while back. He starts by helping you get PHP7 installed (from source, compiled). Once that's installed and working, he helps you get an extension up and running, in this case the enchant extension. He shows you how to run the tests for the extension and how to write some tests to contribute back to the project. He includes instructions for generating code coverage reports, walks you through some sample code and a link to a page with more information if you get stuck.

0 comments voice your opinion now!
testing improving extension php7 version phpt unittest coverage gophp7

Link: http://www.freeklijten.nl/home/2015/03/12/Testing-and-improving-PHP-extensions-for-PHP-7

Jani Hartikainen:
What's the difference between Unit Testing, TDD and BDD?
March 02, 2015 @ 09:16:28

On his site today Jani Hartikainen has a new post helping to demystify some potential confusion around unit testing, test-driven development and behavior-driven development. He's talking about them in the context of Javascript in this case, but the fundamentals transfer to just about any other language, including PHP.

When you're just getting started with automating your JavaScript testing, there's a lot of questions. You'll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them? I've talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let's take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.

For each he provides an overview of this basic concepts and a bit of sample code showing it in action. For TDD (test-driven development) there's not really a way to show it specifically in code as it's more of a practice. Instead he gives a "checklist" to follow when practicing it.

Unit Testing gives you the what. Test-Driven Development gives you the when. Behavior Driven-Development gives you the how. Although you can use each individually, you should combine them for best results as they complement each other very nicely.
0 comments voice your opinion now!
bdd unittest tdd testdrive behaviordriven development introduction

Link: http://codeutopia.net/blog/2015/03/01/unit-testing-tdd-and-bdd/

Snack Overflow:
Unit testing static calls without refactoring the world in php
February 27, 2015 @ 11:55:06

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

0 comments voice your opinion now!
unittest static method refactor proxy object mock tutorial

Link: http://tech.graze.com/2015/02/26/unit-testing-static-calls-without-refactoring-the-world-in-php/

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

Link: https://blog.bitexpert.de/blog/running-phpunit-via-phing-on-hhvm/

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

Link: http://www.sitepoint.com/testing-apis-raml/

SitePoint PHP Blog:
API Client TDD with Mocked Responses
February 19, 2015 @ 12:57:51

The SitePoint PHP blog has posted the third part of their series guiding you through the creation of your first PHP package with a look at mocking API responses in unit tests created via the TDD (test-driven development) process.

In parts one and two, we built some very basic functionality and used TDD with PHPUnit to make sure our classes are well tested. We also learned how to test an abstract class in order to make sure its concrete methods worked. Now, let's continue building our library.

He starts with a bit of catching up to ensure everyone is on the same page in the development process. From there he starts in on the mocking of the API, preventing the need for the (slow) external requests. He shows some updates that are needed to the main DiffBot class, the factories/entities for making objects for requests and examples of putting these to use in a few tests. Finally he shows the creation of the mocks themselves and the result from a sample test.

0 comments voice your opinion now!
mock response tutorial unittest testdrivendevelopment api client

Link: http://www.sitepoint.com/api-client-tdd-mocked-responses/

SitePoint PHP Blog:
Basic TDD in Your New PHP Package
January 28, 2015 @ 12:27:17

The SitePoint PHP blog continues their "How to Build Your Own PHP Package" series with their latest post (part two of the series) covering the use of test-driven development while working on the package code.

In part 1, we set up our development environment, baked in some rules as inherited from The League, and created two sample but useless classes - Diffbot and DiffbotException. In this part, we'll get started with Test Driven Development.

He starts by briefly introducing PHPUnit, a PHP-based unit testing tool, and how to use it to generate the HTML version of the code coverage report. He helps you define a good phpunit.xml configuration file and how to execute a first sample test (code provided) from inside PHPStorm. From there he adds one some more complex testing of exception handling and checking the class types. With this foundation, he moves into the test-driven development (TDD) practices. TDD means writing the tests before writing the code to make those tests pass. He gives an example of this and shows how test abstract classes too. He then comes back around and writes the code to satisfy the test.

0 comments voice your opinion now!
tdd package bestpractice unittest testdriven development tutorial

Link: http://www.sitepoint.com/basic-tdd-new-php-package/

Joe Watkins:
Mocking PHP
January 19, 2015 @ 12:23:39

In his latest post Joe Watkins talks about mocking PHP. No, not making fun of the language but rather mocking internal PHP functions and methods as a part of unit testing your application.

I work on a vast PHP code base, it is 3M LOC of PHP alone. It's somewhere between legacy and modern, work is ongoing. [...] When I joined the current project there were many many tests, they relied upon the kind of unholy magic that runkit allows you to perform, for the most part this worked okay for a while. However, runkit inexplicably caused many of the tests to fault, either at shutdown, or at random.

[...] So we were in a bit of a jam, I've always found runkit to be quite awkward, and now I'm staring its source code in the face knowing it represents a road block to my goal of running the latest stable versions of PHP, with the first decent optimizer that ever existed for Zend. I tackled the problem with code, code which I was allowed by my gracious employer to open source (the uopz extension).

He goes on to talk about what the actual root problem he was trying to solve was (dodging code with built-in functions), the "obvious" way to solve it using runkit or the more modern solution that uses the uopz extension. He provides an example of it in use mocking the fopen function with a "uopz_function" wrapper.

0 comments voice your opinion now!
mock internal method function extension uopz unittest

Link: http://blog.krakjoe.ninja/2015/01/mocking-php.html

Pádraic Brady:
Lies, Damned Lies and Code Coverage Towards Mutation Testing
January 14, 2015 @ 12:20:29

In his latest post Pádraic Brady talks about lies, damned lies and code coverage and how that relates to something called "mutation testing."

I spent the vast majority of 2014 not contributing to open source, so I kicked off 2015 by making Humbug available on Github. Humbug is a Mutation Testing framework for PHP. Essentially, it injects deliberate defects into your source code, designed to emulate programmer errors, and then checks whether your unit tests notice. If they notice, good. If they don't notice, bad. All quite straightforward. [...] This article however is mostly reserved to explain why I wrote Humbug, and why Mutation Testing is so badly needed in PHP. There's a few closing words on Mutation Testing performance which has traditionally been a concern impeding its adoption.

He starts off by talking about the idea of "code coverage" when it comes to writing unit tests...and how 100% coverage usually ends up being a lie. He points out that the current methods of line-based coverage metrics can lead to false results and that it's more about test quality rather than volume of tests. He then moves into talking about mutation testing and where it fits in the test quality puzzle. Finally, he mentions one thing to watch out for when trying out mutation testing and the performance jump (longer, not shorter) it can introduce into your testing cycle.

0 comments voice your opinion now!
mutation testing humbug unittest codecoverage lines

Link: http://blog.astrumfutura.com/2015/01/lies-damned-lies-and-code-coverage-towards-mutation-testing/

Dave Marshall:
Probing Test Suite Quality with Mutation Testing
January 08, 2015 @ 12:09:42

In this recent post to his site Dave Marshall looks at a method for evaluating the overall quality of your suite of unit tests with help from mutation testing.

100% code coverage should never really be a goal. [...] I feel pursuing 100% coverage in a PHP project is a particularly poor idea as our tooling generally only provides Line Coverage. [...] There are more reasonable coverage metrics to use to measure the quality of a test suite. Sebastian Bergmann and Derick Rethans are working hard on bringing some of these options to us, but for now we're limited to line coverage.

He talks about the difference between line, branch and condition coverage types (with code examples) and which allows for more effective and quality tests to be written. He then talks about the results of an experiment to achieve 100% coverage on the Router component in the Aura project. He found the problem using mutation testing - changing values in the production code to make sure the tests break. He also links over to a new mutation testing tool that's been released to help with this kind of thing, humbug, and some of the results it can report.

Mutation testing is a great thing to have a grasp of in theory, but it's not particularly easy to practice. The tools are very hard to write and then their output is often hard to understand or interpret effectively. I wouldn't recommend practicing with mutation testing on a regular basis, but it's certainly worth considering on the odd occasion.
0 comments voice your opinion now!
test suite quality mutation testing unittest coverage

Link: http://davedevelopment.co.uk/2015/01/07/probing-test-suite-quality-with-mutation-testing.html


Community Events

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


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

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework