On the Laravel News site there's a new tutorial posted introducing you to testing with PhpSpec, a specification-driven testing tool that helps you model the specification your application needs to match.

PhpSpec is a testing tool based on the concept of emergent design using specification. You may have heard of Behavior Driven Development (BDD), and PhpSpec is a tool to use at the spec level or SpecBDD. We also mentioned PhpSpec in our recent roundup of Laravel Testing Resources, which includes ways you can incorporate PhpSpec into your Laravel workflow if you are interested in trying out SpecBDD.

If you’ve never tried PhpSpec, one of the things that I love about PhpSpec is that the process generates code for you and guides you through the SpecBDD process through the command line. Let me show you what I mean with a quick tutorial.

The tutorial then walks you through the installation of PhpSpec and how to run it from the command line before making any tests. They then walk through the configuration of the tool and share a sample workflow with seven steps including describing a specification, writing out expected behavior and verifying the behavior. Code examples (and command line calls) are included in each step of the way, defining an example "calendar" specification with the common functionality (add, subtract, divide, etc). The post finishes with some links to where you can find more information about PhpSpec and spec driven development.

On thePHP.cc blog Stefan Priebsch offers up an interesting opinion about code, developers and understanding - developers shouldn't code.

The ultimate problem with program code seems to be that no human really understands it. Sure, we can look at a short piece of code and be relatively clear on what it does, but can we still do the same thing with programs that span tens or even hundreds of thousands of lines?

[...] Well, sometimes I get a strong feeling that there is a shortage of good programmers, because I often find myself looking at legacy code, being unable to tell what it does, at least with reasonable certainty. [...] Personally, I already consider code to be problematic when there is a reasonable amount of doubt as to what it does (and why it exists). To me, uncertainty and discussions are a sure sign of bad code. Call me picky, but years of experience have taught me that this level of strictness makes sense.

He suggests that the fact a developer cannot recognize what current code is doing doesn't make you a poor developer, but the opposite. He talks some about the meaning of the word "code" and how it is written for a machine to understand, not a human. He ends the post talking about testing your code to provide an "executable specification" and, despite having this, a human-readable spec is still a requirement (like it or not).

Code Climate, the popular static code analysis service, has made an announcement that will definitely help make checking your PHP application for quality and security issues easier - the release of the Code Climate Platform. This platform provides, among other things, a command line tool that you can use to run their analysis rules on your own systems.

Today, we’re thrilled to launch the Code Climate Platform − the first open, extensible platform for all types of static analysis. [...] What does this mean exactly? First, we’re open sourcing our analysis tools, including the engines and algorithms we use to evaluate code. We’re also enabling anyone to write static analysis engines that run on our servers by following a simple specification. [...] Finally, using our new Code Climate CLI, you can now run any Code Climate-compatible static analysis on your laptop – for free.

This is a great step forward to helping ensure the overall quality of your codebase and makes it even easier than having to rely on a fully external service for the results. Plus, with the specification you can write rules and customize the checks according to your application or framework of choice. They have a developer program you can register for to find out more information about that.

Marc Aube has a new post to his site that introduces you to the specification design pattern, a technique that's useful for ensuing the current state of an object is valid.

The specification pattern is a software design pattern used to codify business rules that state something about an object. These simple predicates determine if an object's state satisfies a certain business criteria. They can then be combined to form composite specifications using logical operators. Use a specification to encapsulate a business rule which does not belong inside entities or value objects, but is applied to them.

He suggests a few things the pattern could be useful for like validating the current state or define how an object should be created. He gives a few more "real world" examples and then gets into the code to create a custom specification. In his "CustomerIsPremium" spec he defines a single method on an interface to determine if the Customer given is correct. He then creates a class instance and encapsulates the logic inside its "isSatisfiedBy" method. He also includes a bit more complex example, showing how to create a composite specification for handling grouping like "and", "or" and "not" assertions. Finally he looks at how to build specifications that can be passed in and used as selection criteria. He does point out that this can leak database handling into the specification layer, however, and should really be avoided without a inversion of control method in place.

Similar to how the language specification was released for PHP a little while back, the HHVM team has announced a new specification for Hack, the language they've created as a part of the HipHop VM project that's similar to PHP.

When we announced Hack, we were very excited for the community to get their hands on a programming language that has helped Facebook engineers become more productive in their day-to-day development and became, alongside PHP, the language used when developing applications running on HHVM. At the time of release, we had documentation geared for the programmer using Hack to develop applications. However, we did not have official documentation for those that might want to create a Hack implementation of their own or something like a Hack conformance test-suite. This specification fills that gap. It is the document for the Hack implementer, and an excellent supplemental document for the Hack user.

The remainder of the post talks about some of the reasoning behind creating the specification, pointing to resources where you can help contribute and a few thanks to some of the people that worked on it.

In a new post to his site Dave Hulbert has shared some of his thoughts about the PSR-7 standard, a HTTP proposal for HTTP handling.

PSR-7 contains interfaces for HTTP messages. These are like Symfony Kernel's Request and Response interfaces. Having these new interfaces would be great for the PHP community but there's a couple of issues with their current state that I'm not happy with.

One of PSR-7's goals is "Keep the interfaces as minimal as possible". I think the current interfaces are not minimal enough.

He breaks down his thoughts into a few different sections covering ideas around:

• Immutability and PSR-7's enforcement of mutability
• Being too strict to the (HTTP) spec
• Splitting client and server message interfaces
• Writing and reading from StreamableInterface

He sums up his thoughts under each section pretty quickly. If you haven't heard much about the PSR-7 proposal and want more context on what he's referencing, check out this proposal (or other posts sharing opinions from other developers).

On The Changelog podcast today hosts Adam and Jerod talk with Sara Golemon (of Facebook) about the PHP specification that was released a bit back by a group, largely at Facebook, to help define how the PHP language functions.

Some of the topics mentioned in this episode include:

• HipHop VM (HHVM)
• the php.internals mailing list thread about the specification's release
• Sara's extensions book
• The Hack language
• the AST and switch default multiple RFCs

You can listen to this episode either through their in page audio player or by downloading the mp3. If you enjoy it, be sure to subscribe to their feed and get the latest updates as they're released.

On the Inviqua techPortal today Marcello Duarte lists out his top ten favorite limitations with the PhpSpec testing tool. PhpSpec is a tool where the tests are driven by specifications, focusing on the "how".

PhpSpec is enjoying a growth in popularity lately, probably related to the recent release of 2.0. Lots of people have been playing with it and trying to get to grips with what it can do. Naturally they try to do the same things they would with other testing tools. Soon they find out they can’t. “Oh! This PhpSpec has some many limitations… I can’t do this… I can’t do that…”. Ironically, other people make positive comments about the same “limitations”. So I decided to publish a list of my top ten favourite limitations of PhpSpec, and why I love them so much.

His limitations list includes things like:

• I can't test private methods
• You can’t have code coverage
• I can’t use a data provider
• My tests can’t follow a code standard

Check out the full article for more of his list and some code examples ot help clarify each topic.

In his most recent post Marc Morera says bye bye to Symfony and "hello to PHP". Confused? His point is that using the Symfony components as a whole in the framework isn't the only option anymore. You can use them just as effectively as pieces of a larger PHP project, puling them in as needed.

The reason of this post is just to tell you, with a simple example, how to say Bye Bye, Symfony! and say Hi PHP!. This really means uncouple from Symfony Components and still use them as the default implementation, while we can securely remove, from the composer require block, our Symfony dependencies.

He starts off with a simple example showing how to use Symfony's "UrlGeneratorInterface" to create a URL output class that can be injected to use in the route handling of the application. He then moves on to a more real-life example (a metaphor) using a USB connection and the adapters/cables that could be involved to connect various devices. He then shifts back over to the world of code and describes a specification interface that can be used with the URL generation and remove the Symfony dependency from it. On top of this he builds an adapter object that brings the Symfony component back into the picture and abstracts it out a level to make for more flexibility and testability in the long run.

We win maximum implementation flexibility and minimum coupling. Would be wise to say that a PHP project should tend to this thought, but once again, it depends on many factors. [...] Using ports and adapters is really a great tool for those who want to uncouple from implementations and a great pattern if you develop open source. Open source should satisfy as people as possible, so remember, specify and then implement.

In a recent message to the PHP internals mailing list Sara Golemon has announced the development of a PHP specification, a document formally defining the interfaces and structure of the functionality of the language. The effort is being spearheaded by a group at Facebook.

We (As in PHP) have been talking about making a spec for the PHP language for a LONG time. With PHPNG around the corner, the need for a formal spec is even more important so that we can reliably ensure that PHP.Next matches PHP 5.6's behavior as much as possible. Meanwhile, other implementations of PHP (like HHVM) should be as spec compliant as possible so that we don't see the language bifurcate. To that end, we (as in Facebook), have been putting together a formal language spec for PHP (using PHP 5.6 as the source of truth) along with an additional conformance test suite (which compliments Zend/tests).

An initial version (a "sneak peek") has already been posted providing a great start to the effort. There's already been a lot of support for the project in the community and some of the concerns around workflow and maintenance are already starting to be addressed.