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

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

Mathias Verraes:
Economy of Tests
January 05, 2015 @ 11:48:02

Expanding on the previous post about how much testing may be too much, they're back with another post in the series, this time focusing on the "economy of tests". This time Mathias is joined by Konstantin Kudryashov as a co-author.

A common complaint with teams that first try their hand at automated testing, is that it is hard, costly, and not worth the effort. On the other hand, supporters say that it saves them time. In this post, we'll try to add some nuance to the discussion. We'll take a look at how different levels of automated testing affect the cost of development, both in the short and the long term, for both greenfield and brownfield projects. Finally, we'll look at a simple strategy for introducing tests and migrating them across test levels, in order to reduce maintenance costs.

They start with some baseline definitions so everyone's on the same page - unit test, integration testing and system testing. The article also covers some of the basic kinds of testing metrics including execution speed, fragility and understandability. It then moves on and looks at the other major final factor in the overall cost of testing, the age of the project (new vs existing). He mentions the Testing Pyramid, how it's recommended to migrate tests and some of the common opposing forces to the test migration/creation.

0 comments voice your opinion now!
unittest testing economy existing new project definition pyramid

Link: http://verraes.net/2015/01/economy-of-tests/

Mathias Verraes:
How Much Testing is Too Much?
January 02, 2015 @ 11:55:43

In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles - as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn't tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.

0 comments voice your opinion now!
unittest testdrivendevelopment tdd too much overdesign refactor delete

Link: http://verraes.net/2014/12/how-much-testing-is-too-much/

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

Link: http://robertbasic.com/blog/mocking-hard-dependencies-with-mockery


Community Events

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


language interview framework opinion extension threedevsandamaybe podcast api laravel library introduction unittest series release laravel5 symfony security voicesoftheelephpant version community

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