News Feed
Jobs Feed

News Archive
feed this:

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

HipHop VM Blog:
Compatibility Update
April 22, 2014 @ 09:16:38

The HipHop VM blog has a new post today with some updates around the compatibility work they're doing getting popular PHP projects to work 100% on the platform (and have all unit tests pass).

Earlier this year we set an ambitious goal of passing the PHPUnit test suites of 20 popular frameworks by the end of June; at the time, we were passing on only 6! With a huge amount of help from the community (especially our OpenAcademy students), we're proud to have hit this goal more than 2 months early, and we have more frameworks expected to reach 100% shortly.

Included in their list of projects/frameworks are things like Assetic, Composer, Doctrine2, Guzzle (v3), Laravel, Mockery and Monolog. Now that they've made significant strides to get the HHVM up to a greater level of compatibility, they're going to focus in on the issues list from GitHub to resolve problems there.

0 comments voice your opinion now!
compatibility update framework project unittest bugs issues


Federico Cargnelutti:
TDD Checking the return value of a Stub
April 16, 2014 @ 10:25:15

Federico Cargnelutti has a helpful post to his site today for the unit testing/TDD crowd about checking the retuned value from a stub of an object in your tests. He's using the built-in mocking framework here, not something like Mockery.

State verification is used to ensure that after a method is run, the returned value of the SUT is as expected. Of course, you may need to use Stubs on a test double or a real object to tell the object to return a value in response to a given message. [...] In PHP, for example, you dynamically type the return value within the body of the method. This means that PHP mocking libraries cannot check the type of the return value and provide guarantees about what is being verified. This leads to the awkward situation where a refactoring may change the SUT behaviour and leave a stub broken but with passing tests.

He gives an example of a few classes - a Presenter and Collaborator - and a test that mocks out the Collaborator instance, calling a "getStories" method on it. He shows a situation where all tests pass in the initial version, but after some changes to the return type, a test that should fail doesn't. His solution for the issue revolves around DocBlock annotations and the Return Value instead of the built-in mock object return method.

0 comments voice your opinion now!
tdd unittest return value stub passing test returnvalue mock

Refactoring Legacy Code Part 2 - Magic Strings & Constants
April 03, 2014 @ 12:47:46 has posted the second part of their "Refactoring Legacy Code" series today continuing on from their beginning of the series. They continue the refactor of their "trivia" application.

Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. We first met our legacy source code in our previous lesson. [...] The time for the first changes have come and what better way to understand a difficult code base than start to extract magic constants and strings into variables? These seemingly simple tasks will give us greater and sometimes unexpected insights into the inner workings of legacy code. We will need to figure out the intentions of the original code author and find the proper names for the pieces of code that we've never seen before.

They talk about refactoring out things like "magic strings" and other hard-coded return values and checks. They mention updating the tests to reflect these changes while keeping an eye out for "magic constants" as well.

0 comments voice your opinion now!
refactoring unittest magic string constant trivia

Test Code Coverage From Myth to Reality
March 31, 2014 @ 11:50:09

There's a good post over on the site today talking about unit testing, the myths around code coverage and why it may not be as important as you think.

Most cubicle workplaces disappeared and programmers started loving their craft. With the advent of Agile techniques and the Software Craftsmanship movement, many new tools emerged to help the programmer and the process. TDD is slowly becoming the de facto way of writing code and the secrets of SCRUM or Kanban were revealed even to the programmers in the darkest corners of the cubicle world. Automated testing and test driven development (TDD) are some of the essential techniques Agile provided to us programmers. And a tool that comes with those methodologies is used to produce test code coverage, which is the topic of this article.

The article starts with a brief definition of code coverage and gets right into an example class, PHPUnit test and the results of a code coverage generation. They show both output options, the text-only output and the full HTML output with clickable links and visualization of the covered lines of code. There's also an example of generating the coverage inside an IDE (PHPStorm). The post finishes with a look at the myths of code coverage including: "100% covered is bug free" and that "gaming the system" is pretty easy.

0 comments voice your opinion now!
codecoverage unittest phpunit tutorial introduction


Matthias Noback:
Test Symfony2 commands using the Process component and asynchronous assertions
March 24, 2014 @ 10:49:13

Matthias Noback has a new post today showing you how to test Symfony2 commands that use the Process component. More specifically, his tests revolve around the ones that use asynchronous assertions in the testing to remove weird behaviors that could be caused by multiple processes running them simultaneously.

Usually you would test a console command using the ConsoleTester class as described in the official Symfony documentation. But we can not use it in this case. We need to isolate the process in order for pcntl_fork() to work correctly, otherwise the PHPUnit test runner itself will be forked too, which will have the effect of running all the following unit tests twice (which can have very strange effects on the test results).

He shows how to use the Process component to start up a new process (the daemon) and check that the PID file exists. He includes an example of a "probe" to determine what processes are running and preventing them from stepping on each other.

0 comments voice your opinion now!
symfony2 command process component asynchronous assertion unittest phpunit


Master Zend Framework:
Simplifying Unit Testing (and asking for help when needed)
March 20, 2014 @ 11:54:16

On Matthew Ssetter's "Master Zend Framework" blog today he talks about simplifying unit testing and some of his experience with getting too complicated in his own testing practices.

Recently I was a bit stuck, trying to figure out how to test a section of an application I've been developing. Specifically, I was trying to mock a HydratingResultSet in a controller test, so it could be the return value of a method call on a datasource, my controller needed. I was sure it was the right approach to help ensure the functionality in question was working properly. But no matter what I tried, my tests didn't work, because I wasn't mocking it correctly. [...] I asked for help [on IRC], laying out the problem as I saw it. The first response which came back, from Ocramius, stopped me dead in my tracks: "Why are you trying to do that?"

He includes a bit of background on what he was trying to test and the functionality around it and how, when he stopped to think about it, wondered why he was testing it too. He talks about the refactor he made to his code with a positive end result - the tests now passed. He suggests a few questions to ask yourself when writing your tests such as "am I doing too much?" or "am I testing code in the right place?" Chances are, if you step back and really look at what you're testing, you might realize that the answer to these questions is just to simplify.

He finishes the post with a few suggestions, some of his own personal favorites, of places you can go for help when questions do pop up. He points out that the usual excuses shouldn't be a blocker on asking for help. He is "encouraging you to set your pride, ego and excuses aside and when you're stuck: ask for help."

0 comments voice your opinion now!
testing simplify unittest zftalk help question


The Blog:
Disintegration Testing
March 20, 2014 @ 10:20:25

In this new post on blog today Sebastian Bergmann relates the unfortunate disintegration of the Mars Climate Orbiter (back in 1999) back to a lesson on software testing and errors.

One of the most important tasks in software testing is to find the smallest scope in which a test case can be implemented. The smaller the scope in which a test is run, the faster it can be executed and the more precise its result. Unit Tests exercise one unit of code in isolation from all collaborators. Integration Tests verify the interaction of two or more collaborators in isolation from the rest of the system. Edge-to-Edge Tests run the software as end-to-end as possible in a single process (and without using a web browser or a web server). End-to-End Tests, or System Tests, look at the whole system and in the case of a web application send a HTTP request from a web browser to a web server running the software to inspect the HTTP response that is sent back.

He talks some about the difference between unit tests and acceptance tests and how "easy and seductive" functional tests can be over unit testing. He points out how fragile (and sometimes slow) this can be though, and how their failure only shows a problem and not where it is.

The promise of being able to develop both the business model as well as the software that implements it in an agile fashion should be reason enough for enterprises to invest in a modern, highly decoupled software architecture. And when the members of the software development team communicate well, both among themselves and with the other stakeholders, then there is not much that can really impede the success of the project.
0 comments voice your opinion now!
unittest functionaltest testing software nasa orbiter


The Blog:
PHPUnit 4.0 Test Proxies
March 12, 2014 @ 10:13:08

On blog today there's another post looking at an improvement in the latest release of the popular PHP unit testing tool, PHPUnit 4.0.0. In the post Sebastian Bergmann looks at test proxies.

One of the highlights of PHPUnit 4.0, which was released last week, is improved support for integration testing through so-called test proxies. [...] PHPUnit has had built-in support for stubs and mocks for quite some time. These stubs and mocks can be used in every context where an object of the original class is expected. As it should be, the code of the original class is not executed when a method is called on the stub or mock. [...] PHPUnit 4.0 introduces the concept of test proxies [...] to have an object that provides the same API for expectations as a mock object while at the same time proxying method calls to the original class.

He includes some code examples to help illustrate. He creates a "SimpleWorkflow" class and shows how to test the execution of its "doWork" function to return the correct kind of "Result".

0 comments voice your opinion now!
phpunit test proxy unittest introduction release


The Blog:
PHPUnit 4.0 Code Coverage Improvements
March 10, 2014 @ 10:47:41

The latest version of the popular PHP unit testing tool PHPUnit has officially been released (version 4.0.0) and comes with some nice improvements. In this post to the PHPcc blog Sebastian Bergmann talks about enhancements in one area - code coverage reporting.

One of the highlights of PHPUnit 4.0, which was released last week, is an improvement of the @covers annotation and the addition of the @uses annotation for better code coverage analysis.

He includes a few simple code snippets showing you how the "@covers" annotation has been working and how it can be used in both strict and non-strict modes. He also introduces the "@uses" annotation to define which objects the test is using and how the two interact. He finishes off the post with a mention of the "--strict-coverage" command line flag (or the more general "--strict").

0 comments voice your opinion now!
code coverage improvements phpunit unittest


HHVM Blog:
Tracking Parity
March 04, 2014 @ 10:43:13

On the HHVM blog today there's a new post shows how far along they are with parity with the PHP language based on the tests from a sampling of several large PHP-based projects.

HHVM has a large suite of unit tests that must pass in several build configurations before a commit reaches master. Unfortunately, this test suite passing doesn't tell you if HHVM can be used for anything useful - so we periodically run the test suites for popular, open source frameworks. [...] The frameworks test page is now public, as is the JSON data backing it (which you're welcome to use).

They look briefly at what exactly is tested (latest stable version, with exceptions) and how it all works. The tests are run once an hour and are based on a completely clean build of HHVM in "csv" mode. The results of the tests are automatically pushed into the MySQL+Memcached system reporting system, accessible via the JSON API.

0 comments voice your opinion now!
parity tracking unittest framework hhvm project json api


Community Events

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

database hack facebook framework release install security hhvm symfony2 performance unittest application package language introduction podcast opinion component support composer

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