I think that we are witnessing the first wave of new testing tools in the PHP community that allow developers to wrap their applications in automated tests. I am familiar with the BDD-style that is being promoted in PHPSpec, through my work with Behat to create automated user acceptance tests. I think if you want a tl;dr version of PHPSpec I would tell you "write hybrid unit/integration tests using plain language".

He notes that writing code to match a specification has similar concepts to using unit testing for TDD (with something like PHPUnit). He points out a few interesting things like the use of mock objects and the fact that you'll still need to write some code to make tests work - that's unavoidable right now.

First of all, phpspec2 is not a testing framework. It's a SpecBDD tool. It means, testing is not our primary aim. Tool's job is to enforce and make SpecBDD in project flawless and phpspec2 uses all available methods to do that - state of the artformatters, class and method generators and lot of othe fancy buzzwords :) Today, i want to explain you the heart of phpspec2 - SUS, collaborators and prophets.

He starts off defining specifications as a list of behaviors about how an object should behave and the abilities that come with them (like "getTitle"). He shows assertions, like "shouldReturn", and how you can use Collaborators to evaluate the interfaces between objects.

Earlier this week, I unsubscribed from the mailing lists of a pair of Open Source projects. About two years ago when I found the projects, they involved fascinating topics in under served niches. One of those niches - the one customer/user-facing - is still there and under served, but that's not relevant in the current discussion. In reviewing the activity on the mailing list, I noticed some interesting things: activity was very high, there were some smart people involved in the discussions and there was a lot of discussion on what should be done but nothing actually getting done.

He notes that without a codebase to work from, there can't be any direction because no one knows where things are headed or what can be done to improve it. Writing up a spec to guide the development can help, but then you still have the pitfall of who should write that spec.

Microsoft has some catching up to do in terms of standards compatibility, but they are also doing some good things with this browser. They are bringing some much needed web-standards compatibility, in addition to some JavaScript performance enhancements.

Handy new features include better HTML5 support, CSS3 support, XHTML parsing, Javascript compilation and an overall trend towards a more standards-based approach that Microsoft hasn't worried about in a good while now. He also mentions the OData toolkit that lets your web applications speak the same "language" according to Microsoft's more unified specification.

Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly. "If it takes more than 15 minutes to determine what it is that you're building, the spec wasn't done properly".

He suggests that not a single line of code should be developed before the spec is completed and, since developers usually aren't the ones creating the spec, they need to have a clear, concise definition of what's expected before hand.

In the time that I have developed software, I don't know that I've ever met a developer who got excited about writing specs for anything. In fact, most developers loathe writing specs, or developing schedules of any kind. [...] Businesses need schedules to know when products will be finished and schedule things like trade shows, product launches, and write contracts with clients who need or want a particular product.

He has a few recommendations for things that could make the process a little easier including the fact that specs should not be considered documentation, that the developers should be the ones creating them and that scheduling out the development time line isn't all about the actual development.

One of the latest (sort of) crazes sweeping the net is APIs, more specifically those that leverage REST. It's really no surprise either, as consuming REST APIs is so incredibly easy… in any language. It's also incredibly easy to create them as you essentially use nothing more than an HTTP spec that has existed for ages.

He looks at what REST is - both the request and response sides - and some of the PHP code you can use to create your own service. His example defines all of the HTTP codes and uses a processRequest function to handle the incoming request. The response is pushed back out from the processResponse method and even includes an extension of the class to handle XML requests if they're POSTed.

I thought I'd share a PHP library implementing this idea by Evans and Fowler. Written for PHP5, it's a library for defining custom specifications using composition and inheritance.

He gives the example of "Person" objects with name and age properties. A search might involve looking directly at the properties to location one that's, say, younger than 35 and has a last name of Johnson. His specification class replaces this and makes it more reusable by applying things like GreaterOrEqualSpecifications and EqualSpecifications to standardize the evaluation. Then its just a quick call to the isSatisfiedBy method to check for correctness.

Today Microsoft announced a significant initiative which aims to provide the developer community with access to a large number of Microsoft protocols and file formats. [...] With Microsoft opening up their specifications under the OSP, open-source communities like Zend Framework are now able to build such solutions without fear of litigation. There are many other areas where it will benefit open-source projects including Samba (SMB), FreeTDS (SQL Server), Mono (.NET), and others...

He shares his thoughts on the winners (Microsoft themselves, Open Source community) and losers (Microsoft's competitors, Linux) on the deal and the beneficial impact he thinks it will all have on the PHP.

Because I love all things OpenID related and am an OpenID "pusher" in Europe (blame the OpenID Europe Foundation membership on Snorri Giorgetti), I'll be proposing a PHP5 implementation of OAuth to the Zend Framework (assuming no other OAuth proposal) and PEAR (PEAR because that's now the home of my OpenID For PHP library under proposal).

You can get more information about OAuth from the project's website.