Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

Looking from outside both Symfony2 and ZF2 is full of standalone components. But the reality is not the same. Though Symfony2 components are split into each components in github, you cannot give a pull request to that component. The tests for all the components still resides in the core.

He points to the Aura framework project as a good example of how to make a truly component-centric set of tools complete with tests bundled into the component's download right next to the source.

Last month, I wrote a post that outlined 3 ways to test PHP applications in Windows Azure, and since then I've covered two of those approaches: Running PHPUnit in Windows Azure (uses RDP) and Automating PHPUnit Tests in Windows Azure. In this post I'll cover how to use a web-front end (VisualPHPUnit specifically) to run tests in Azure.

The process is really simple - it's basically three steps (after the VisualPHPUnit install):

• Edit the configuration file to point to the right tests directory
• Password protect the VisualPHPUnit directory
• Deploy your application by following the instructions here

The test suite can't test everything. You should test your applications with your new PHP too. This gives load and real-life testing not possible with PHP's script based test suite.

[...] The tests in ext/oci8/tests verify the behavior of the OCI8 extension. To run them follow these steps.

There's four steps he gives that will help you check your Oracle compile installation including what the response of the test results will look like.

Intrigued as much by this project, as I was by the fact that Ed wrote me and told me it was time for me to interview him, I called Ed and we talked about the project.

They talk about where the idea for the tool came from, one of the targets for the use of the project (those on shared hosting), and the mention that it is modular in design and they are more than happy to have developers work up tests to be sure things are working 100% correctly.

Seems Philip and colder were talking on the IRC about possibly using the php doc examples to automatically generate some phpt tests to make sure the examples in the docs worked correctly. I personally think it is a great idea for another reason - it would give the QA team a base listing of phpt tests for the various PHP functions. With that base listing it would be easier to modify/add to the various phpt tests to cover the boundries of the function.

A script to implement this feature is already in the works - a preview of it can even be found here.

A PDF of our slides is now available: Power PHP Testing (PDF).

Geoff also has some tarballs available that let you test a very simple PHP library (functions.inc) with Apache-Test, Simple-Test, PHPUnit, and phpt: http://people.apache.org/~geoff/power-php-testing

He also gives some other resources for finding out more about Apache/PHP testing as well as a brief mention of TAP (Test Anything Protocol)...]]> Mon, 19 Dec 2005 06:46:17 -0600