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

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

AirPair.com:
Best Practices for Modern PHP Development
December 05, 2014 @ 09:50:22

On the AirPair site today they've posted an article from developer Brian Fenton covering several things he sees as the best practices for modern PHP development, a listing of several tool, practices and suggestions to improve your skills as a PHP developer and bring them to the next level.

He breaks it down into five main sections (each with their own subsections):

  • Setup and configuration
  • Use Composer
  • Follow good design principles
  • Object calisthenics
  • Unit testing

Some of the points made under each of these sections include suggestions about using sensible defaults, installing and using Composer, the SOLID design principles and unit testing tools. Check out the full post for more great suggestions and techniques to improve your skills.

0 comments voice your opinion now!
bestpractices modern development tips list composer objectcalisthenics unittest

Link: https://www.airpair.com/php/posts/best-practices-for-modern-php-development

NetTuts.com:
Unit Testing Succinctly Why Unit Test?
October 16, 2014 @ 12:06:05

NetTuts.com has kicked off a new series of posts today that answers the question "Why unit test?" The series, Unit Testing Succinctly aims to define what unit testing is, approaches to implementing them and what they can do to help you and your application.

The usual mantra we hear regarding any software methodology is that it improves usability and quality, reduces development and testing time, and brings the product to market faster and with fewer bugs. These are lofty goals, but I have yet to see a methodology deliver the Grail of software development. Ultimately, the primary reason to write unit tests is to prove correctness, and this happens only if you write unit tests well.

In this first post they cover three of the more general reasons for making the dive into unit testing your applications at all. These are more "business value" kinds of ideas but they trickle down into the development level, providing value for the developers too.

  • Measuring Correctness
  • Repetition, Repetition, Repetition
  • Code Coverage

Their main point to reinforce is the first of the three, though. Unit testing helps to measure and ensure correctness of both the code itself and the functionality it performs.

0 comments voice your opinion now!
unittest introduction why correctness coverage repeatability

Link: http://code.tutsplus.com/articles/unit-testing-succinctly-why-unit-test--cms-22410

Dave Marshall:
Mockery Spies
October 09, 2014 @ 10:29:08

In his latest post Dave Marshall takes a look at a handy feature of the Mockery mocking tool (helpful for unit testing) and how to use them in your testing.

Spies have been on the cards for mockery for a long time and even after putting together an implementation in February, I kind of stalled out on making a decision on the public API. Fast forward a few months and I figured it was just time to ship it, so I went with the most mockery like API and merged it in. Mockery still doesn't have a 1.0 release, so I can always make changes before we go 1.0.

For those not familiar with the concept of "spies" in testing he includes a brief definition and some of the reasoning behind using them. The first is relatively simple: how they can reveal the intent of the test. They also allow for two other types of testing methods, "Arrange-Act-Assert" or "Given-When-Then" thinking patterns. He does mention, however, some of the problems with using spies over mocks (including that they're less precise, possibly leading to looser testing). He finishes up the post with a quick note about partial spies and how they can provide a nice compromise in your testing.

0 comments voice your opinion now!
mockery unittest spies doubles mock compare feature

Link: http://davedevelopment.co.uk/2014/10/09/mockery-spies.html


Community Events





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


opinion laravel unittest framework composer release api conference version podcast community extension voicesoftheelephpant interview list install introduction series configure symfony

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