Planet PHPUnit

Options for setting up a Doctrine database connection when PHPUnit testing symfony plugins

2010-08-29T17:00:42+00:00

It is rarely the case that your unit tests actually test your database. It is however not so rare that the code your unit test tries to cover needs a database connection of some sorts.

In symfony 1.x you will find quite some tightly coupled code. Together with Doctrines (1.x) implementation of the active record pattern you will get a lot of exceptions complaining about no open database connection.

So if your tests need a database connection how should you do that?

I created a little experiment to test setting up database connections. If you’re interested you can reproduce those experiments with the sources on GitHub.

I basically tried a few combinations of the following code.

Setting up a database connection using the settings in the fixture projects databases.yml

Setting up a database connection using Doctrines mock adapter

Findings

You should always set up a database connection using the setUp() method of your testcase or a test method itself if it is the only method requiring a database connection. This way you only use the database when you actually need it.

I am still pretty amazed that using the mock adapter shows no functional difference to sqlite::memory: and is using up the same amount of memory.

Using –process-isolation on PHPUnit when executing a testcase or testsuite will drastically reduce the memory consumption but at the time of writing this (using PHPUnit 3.5RC1) it will produce a strange runtime exception when the database connection is made in the bootstrap file.

Oh and on the GitHub page you can also see the results of the experiments.

Why Doctrine_Core::getTable(‘BarFoo’) is not such a good idea.. when PHPUnit testing a symfony plugin

2010-08-26T20:18:01+00:00

If you have a look at the symfony and Doctrine documentation you will notice that whenever you want to get the table object for a model you will call Doctrine_Core::getTable(‘ModelName’).

Apparently this is considered a best practice however I came to thing quite the opposite.

As you probably know I am quite keen on the topic of unit testing and that is exactly where Doctrine_Core::getTable() gets annoying.

It’s a static method that will be called in many methods of your classes. Mostly actions and components I suppose but also in other places.

Now when you want to test those methods that include a static call like this you will notice that you need to bootstrap a lot of symfony and Doctrine. Many times you will also need to open a database connection. But the method you want to test only calls to database related methods.

I would like to be able to mock all these database related methods in order to optimise execution speed of my unit tests. However you can not mock static methods (with PHP3.5 and PHPUnit 3.5 you will be able to) which means that you need to connect the database.

This may all sound a bit loopy but I just spend several hours optimising unit tests replacing calls to Doctrine_Core::getTable(‘BarFoo’) with new BarFooTable().

Applying best practices for PHPUnit testing symfony plugins

2010-08-25T18:11:16+00:00

By now I have been writing quite a bit about how to utilise PHPUnit when developing symfony plugins. But symfony is of course still bundled with lime so before starting right away every plugin needs to be prepared with small changes like adjusting the bootstrap.

And because all these little changes have to be repeated over and over again for every plugin you start they tend to get tedious.

But I’ve got an idea!

Well credit where credit is due: it was actually Stefan Koopmanschap (skoop) who initially gave me the idea of putting my findings and best practices into a plugin.

So what is to be expected?

Well so far I plan the following three features:

A symfony task to change the default test bootstrap to work with PHPUnit
A symfony task to create a best practice phpunit.xml.dist
A symfony task to create skeleton test cases for classes in your project

Of course the plugin itself will be PHPUnit tested (eating my own dog food).

What would you like to see implemented? Feel free to comment on quora.

[Best practice] How to ship PHPUnit configuration

2010-08-23T16:07:10+00:00

PHPUnit offers quite a lot options to be set as arguments on the commandline. However this is tedious when typing over and over again.

For this reason you can create an XML configuration file phpunit.xml that will automatically be used by the phpunit binary.

Now you may want to include this configuration file in your projects sourcecode to be used by all participating developers and your continuous integration server. But how?

Well, you could just commit the `phpunit.xml` to you repository right?

Well, yes. But then all developers who want to checkout and work on your project will have to use these settings or going through the trouble of maintaining local changes to the configuration or specifying a different one using the commandline.

No! Use `phpunit.xml.dist` instead.

Sebastian made me aware of this and he is right. If you provide a phpunit.xml.dist(ribution) instead then every developer can chose whether to use your configuration or his/her own.

It is also wise to ignore the real phpunit.xml for your repository using .gitignore or svn:ignore or similar. This way everybody can use the settings he/she wants without forcing them onto others.

How can my continuous integration server use the config?

Simple! the phpunit binary is clever enough to use any phpunit.xml.dist file if no phpunit.xml is available.

Setting up Continuous Integration for a symfony plugin using Hudson and Sebastian Bergmanns (PHPUnit) Template for Hudson Jobs for PHP Projects

2010-08-22T19:35:32+00:00

I must admit that I have been lazy with my efforts on continuous integration lately. Eventually my server crashed unnoticed and I didn’t get any emails about broken builds anymore and by now I think I’ve stacked up some work to do.

First of course I’ve got to get my CI server up and running again, that’s why I installed Hudson again.

But there is room for improvement too. Sebastian Bergmann of PHPUnit fame spent some time on a template Hudson job for PHP projects that includes much more than PHPUnit. So I decided to use that!

Goal

What I want to achieve is to setup a project for my symfony plugin sfImageTransformExtraPlugin using the Sebastians template.

Prerequesites

I am assuming that you already have a working Hudson installation and the following plugins installed:

Checkstyle (for processing PHP_CodeSniffer logfiles in Checkstyle format)
DRY (for processing phpcpd logfiles in PMD-CPD format)
HTML Publisher (for publishing the PHPUnit code coverage report, for instance)
JDepend (for processing PHP_Depend logfiles in JDepend format)
PMD (for processing phpmd logfiles in PMD format)
Template Project (for using php-hudson-template as a template for Hudson jobs)
Violations (for processing various logfiles)
xUnit (for processing PHPUnit logfiles in JUnit format)

Setting up the template job

Just as described in the README on GitHub we just checkout the project in to our Hudson jobs folder.

$ cd /home/of/hudson/jobs
$ git clone git://github.com/sebastianbergmann/php-hudson-template.git

And then we have to restart Hudson to take notice of this new job.

The job itself is disabled as it has no subject.

Setting up the real job

So what I want to do is to checkout the current development version of my symfony plugin from GitHub. I also have to checkout it dependencies which are symfony itself and sfImageTransformPlugin which both are available only via Subversion.

I start by adding a new “free-style software project” job with the name “sfImageTransformExtraPlugin”.

First I configure the GitHub source and under the advanced options I configure it to be checked out into a local subdirectory “sfImageTransformExtraPlugin”.

Next I add a build step “Invoke Ant” and under advanced options I point it to the build.xml at “sfImageTransformExtraPlugin/build.xml”.

Last thing to configure is to “Use publishers from another project” and I enter “php-hudson-template” as the template project.

And that all you have to do to setup the project in Hudson.

But of course that’s not all. Two produce all the reports that the template should process and to checkout and update the dependencies we need two more configuration files which are both part of the plugin.

This is more or less a copy of the example from Sebastians GitHub Page with soem slight modifications.

The first target “update” will check out the dependencies from symfonys Subversion repositories in parallel to the plugin itself. The plugin is configured to assume symfony and sfImageTransformPlugin at these locations.

All artifacts such as coverage reports and metrics will be written to a directory “build” which also lies in parallel to the plugin source. All together will produce a directory structure like this.

/path/to/hudson/jobs/sfImageTransformExtraPlugin/build/
/path/to/hudson/jobs/sfImageTransformExtraPlugin/sfImageTransformExtraPlugin/
/path/to/hudson/jobs/sfImageTransformExtraPlugin/sfImageTransformPlugin/
/path/to/hudson/jobs/sfImageTransformExtraPlugin/symfony/

But not all reports that are expected by the template are being produced by this build.xml. The PHPUnit specific reports are configured in the phpunit.xml file.

Adjust these two configuration files for your plugin to your needs and you’re ready to go.

In the following weeks I will write some posts explaining all the results you can now see in your Hudson installation (or in mine).

Conclusion

This template makes setting up Hudson for PHP development so much easier! Great thanks to Sebastian for his awesome work!

PHPUnit 3.5: Less $this Required

2010-08-16T13:45:00+00:00

~~The feature discussed below has been removed from PHPUnit due to community feedback.~~

Over the years, I have gotten quite a few "complaints" from PHPUnit users that they do not like typing $this-> as often as they have to:

<?php
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testPushAndPop()
    {
        $stack = array();
        $this->assertEquals(0, count($stack));
 
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertEquals(1, count($stack));
 
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEquals(0, count($stack));
    }
}
?>

As of PHPUnit 3.5, they can write test code that requires less $this-> statements:

<?php
require_once 'PHPUnit/Framework/Assert/Functions.php';
 
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testPushAndPop()
    {
        $stack = array();
        assertEquals(0, count($stack));
 
        array_push($stack, 'foo');
        assertEquals('foo', $stack[count($stack)-1]);
        assertEquals(1, count($stack));
 
        assertEquals('foo', array_pop($stack));
        assertEquals(0, count($stack));
    }
}
?>

Here's hoping that this makes some people happy :-)

GTAC 2010

2010-07-23T13:20:35+00:00

I have been invited to attend the 5th Annual Google Test Automation Conference, better known as GTAC, in Hyderabad, India in October. I am very much looking forward to discuss cutting edge challenges in test automation and evaluate potential solutions, especially with this year's focus on testability.

Another thing I like about this year's GTAC is that the participants are responsible for selecting the presentations for the conference. Here is my submission:

Challenges in Unit Testing PHP Applications

According to TIOBE, PHP is the most popular programming language after C/C++ and Java. The language has made strong inroads into large-scale, business-critical Web systems. In the six years since the release of PHP 5 -- which not only kickstarted the development of PHP-based frameworks for Web development but also the development of tools for dynamic and static testing techniques -- the PHP community as a whole has developed an increasing interest in developing software that delivers the best possible quality.

When PHP developers start to write unit tests they rarely find themselves without any constraints that are imposed by prior work of less than optimal quality. It is a well-known fact that writing unit tests for legacy code is hard. In the case of PHP it can be even harder: the legacy code has not only been written without testability in mind, but it may have been written for earlier versions of PHP that encouraged practices that make the code next to impossible to unit test.

PHPUnit, the de-facto standard framework for unit-testing PHP code, has some unique features not found in other xUnit test frameworks that allow the testing of untestable code. While developers should not use these features (as they are not required when writing tests for testable code), these features ease the pain of writing tests for legacy code and thus help developers get started with unit testing before they refactor the code for testability.

This session, presented by the creator of PHPUnit, highlights the challenges developers are facing when unit testing legacy PHP code. Some of these challenges will be familiar to developers that use other programming languages such as Java but they will see a new perspective on the problem and different approaches to solve it.

Although I am hoping, of course, that my submission will be accepted by my peers, I know that GTAC will be valuable for me even if I do not get to present: the "hallway track" of GTAC 2008 was amazing.

PHPUnit 3.5: Refactoring to Components

2010-07-23T12:00:00+00:00

When you look at the list of changes for PHPUnit 3.5, you will see that many of them deal with refactoring to components. Here is an overview of these new components:

PHP_CodeCoverage
The collection, processing, and rendering of code coverage information has been factored out into a separate component. A bit more information can be found here.
PHPUnit_MockObject
The functionality to automatically generate an object that can act as a test double for a specified original class has been factored out into a separate component. Do not worry, getMock() and related methods will work just as they did in previous versions of PHPUnit. The refactoring, however, makes the usage of other mock object libraries (such as Mockery or Phake, for instance) easier.
DbUnit
The database testing functionality that is provided by the DbUnit extension and the respective DatabaseTestCase class has been moved to a separate component. Michael Lively Jr, the author of DbUnit, is now able to make releases of the database testing extension on a release schedule that is separate from PHPUnit itself, meaning that I will be even less involved in its development than I have before.
PHPUnit_Selenium
SeleniumTestCase, the Selenium RC integration for PHPUnit, has been moved to a separate component to allow a release cycle separate from PHPUnit itself.
File_Iterator, PHP_Timer, Text_Template
Utility methods to collect files and report resource usage as well as a simple templating mechanism have been moved to separate components so that they can be reused by other tools such as phpcb, phpcs, phpcpd, and pdepend.

Unit testing symfony plugins with PHPUnit – My session at the symfony day 2010. What do you expect?

2010-07-22T04:00:18+00:00

I was asked to speak at the symfony day 2010 in Cologne and I happily agreed to it. My session will be about Unit testing symfony plugins with PHPUnit.

While I have a clear view what to talk about within the one hour I have I wonder what your expectations are?

So instead of writing down what I want to present I ask you to have your say to give a good user experience.

What are the topics you want to hear about?
What is the level of knowledge I should assume the audience to have?
Do you expect a presentation or hands on examples?
Theory or practice?
What should I wear?

Comments please!

Wrapping symfonys functional tests in a PHPUnit test case

2010-07-06T11:50:43+00:00

Yesterday I wrote a lot of functional tests for a symfony plugin that provides and XML web service interface.

Using symfonys functional testing classes this is actually quite easy to do.

But wouldn’t it be cool if you could integrate these tests into your continuous integration service just like PHPUnit tests? Wouldn’t it be cool to be able to generate PHPUnit coverage reports?

Well I thought so too that’s why I decided to write a very simple PHPUnit test case that executes the functional tests (using lime) and runs asserts on the output of those.

<?php
 
/** central bootstrap for unit tests */
require_once dirname(__FILE__).'/bootstrap/functional.php';
/** PHPUnit Framework */
require_once 'PHPUnit/Framework.php';
 
class yourPluginFunctionalTest extends PHPUnit_Framework_Testcase
{
  public function testIndex()
  {
    $this->assertLimeReport('Index');
  }
 
  public function testShow()
  {
    $this->assertLimeReport('Show');
  }
 
  private function assertLimeReport($action)
  {
    ob_start();
    include(dirname(__FILE__).'/functional/yourModuleActions'.$action.'Test.php');
    $output = ob_get_clean();
    $lines = explode("\n", $output);
    foreach($lines as $line)
    {
      if(trim($line) && '#' != $line[0] && '>' != $line[0])
      {
        $this->assertEquals('ok', substr($line, 0, 2), $line);
      }
    }
  }
}

You can see that I used a simple convention how to name the functional tests. There is actually one file per action with the action name encoded in the file name. In the above example I run the tests for executeIndex() and executeShow().

The rest is simple as well (and can for sure be done far more elegant). I just iterate over the lime output and check for result lines that start with ok.

I also wrote a small phpunit.functional.xml configuration file so the coverage reports only considers my module code (all other code is unit tested of course).

<?xml version="1.0" encoding="UTF-8"?>
 
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         colors="false"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false"
         syntaxCheck="false">
 
  <filter>
    <whitelist addUncoveredFilesFromWhitelist="true">
      <directory suffix=".class.php">./modules/yourModule/actions/</directory>
      <directory suffix=".class.php">./modules/yourModule/lib/</directory>
    </whitelist>
  </filter>
</phpunit>

Running this test case is easy.

$ phpunit --configuration=phpunit.functional.xml --coverage-html=/path/to/your/report test/yourPluginFunctionalTests.php

The coverage report comes in quite handy as I can now see which methods are not executed and are probably not needed any longer (I did some heavy refactoring on this).

The only thin I can not get rid of is that lime will only have the last word telling me “# Looks like everything went fine.“.

This is due to limes use of register_shutdown_function() which unfortunately does not have a counter part to unregister..

State of Symfony 2 online conference – a killer feature revealed!

2010-06-22T18:10:41+00:00

Yesterday I attended the The State of Symfony 2 online conference. Actually my first online conference so it was quite exciting.

One of the most exciting questions though was: What is this new killer feature? Well, I made my guess before but lets see if I was right.

A few minutes before the first session there were already more than 100 people connected to the collaboration platform (http://www.elluminate.com/). Not a bad turnout for “just an online conference”.

The tool features moderation, listening as well as speaking, voting, a whiteboard, file transfers, a group chat and probably a lot more. It seemed a suitable choice.

Please excuse this article to be somewhat bullet-point-ish but I wrote most of it while listening to the sessions and I guess you will get the meaning anyway.

Miscellaneous enhancements Fabien Potencier

The philosophy of Symfony 2 is to be as flexible as possible but with sensible defaults so it can be used right out of the box but possible to be changed to everything you need. Symfony 2 now also adapts PEAR standards to allow easy integration of non-symfony libraries rather than setting its own standards.

As much as possible went was put into the components to make sure they don’t depend on the MVC framework and can run standalone. This as well eases the use by Symfony newbies as well as experts.

Fabien introduced the latest additions to the components library.

CssSelector developed from scratch converts CSS selector to their XPath equivalents.
DomCrawler was based on symfony 1 browser class and can navigate the DOM. Its methods are chainable, it can utilise CssSelector but uses XPath internally and its API feels jQuery like.
Browser is an HTTP client implemented in PHP that can even manage cookies.
Finder is completely rewritten from its symfony 1 version and now implements PHPs Iterator interface. It’s chainable and provides easy to use date filters. The method signatures are standardised and instead of file handles it returns SplFileInfo instances. It can also work with streams like on the Zend FWs Amazon S3 Stream.
HttpKernel is a framework construction kit and replaces the former RequestHandler. It has a very simple interface with only two methods getRequest() and handle(). It also includes a Profiler and the WebDebugToolbar functionalities.

All components are decoupled and therefore fully testable.

With these and the already known components Symfony 2 is not yet ready but the main concepts and overall philosophy will not change anymore.

From the Q&A at the end of the session we learned that at this point there will be no migration tool from symfony 1 to Symfony 2 but there will probably be an intermediate layer once Symfony 2 is ready.

However the API can change at any time! So for production use sf1.4 is still recommended!

The first alpha version planned for September.

Symfony 2 Meets Propel 1.5 François Zaninotto

I don’t really use Propel but still I was interested in its latest developments.

Propel 1.5 is fully backwards compatible with Propel 1.3 and 1.4. It’s faster, very IDE friendly, better documented, has three times more unit tests as Propel 1.3 and is fully integrated into symfony 1.4 using the sfPropel15Plugin.

Announced as one of the killer features come the model queries which are supposed to be to SQL what ActiveRecord is to the table row. To me it looked like a clone of Doctrines DQL but with domain specific method names..

Next killer feature and missing in Doctrine 1.2 is concrete table inheritance! But on the database level it is actually denormalised meaning that columns defined on the parent model are stored in the child tables as well for performance reasons. I wouldn’t really consider this to be concrete but composite and I remember having done something similar in Doctrine as well..

The third killer feature still to come will be the aggregate_column behaviour which utilises aggregation functions and stores and maintains their results in extra table columns.

Well, Propel is not dead but I am not convinced of its killer instinct and frankly I am annoyed by all this Doctrine bashing. If Propel is a good ORM (what it is to many users) then I should be able co-exist with other solutions! I think the major difference between Propel 1.5 and Doctrine 2 is that Propel is still an ActiveRecord which some might prefer. Not me though.

Funnily after the presentation a poll was setup whether to prefer Propel or Doctrine and when I had a look it was 76% favouring Doctrine. http://twtpoll.com/r/545mw5. Nowhere near representative but entertaining.

What’s new in the Doctrine 2 Symfony Integration Jonathan Wage

Jonathans session didn’t bring too many news for you when you followed his talks and tweets regularly but it was a good and up to date wrap up of the current implementation.

Next to the DoctrineBundle for Symfony 2 there now is also a MondoDB Object Document Mapper bundle (ODM not ORM!) and a bundle for the beloved Doctrine Migrations with unchanged functionality.

Here’s Doctrines Architecture in a nutshell.

The DBAL is responsible for managing connections and creating/dropping databases and running dql from the command line.
The ORM has the EntitiyManager which persists and retrieves entities. You can have multiple instances (i.e. per database connection) of it.
An Entity is a regular PHP object, no more magic, clean and testable, fast and only limited by PHP and now you can use the constructor as you like to.

One nice little thing I like is the new command line task that ensures your production settings! But also tasks for cache control are a nice addition.

DQL now uses a proper lexer/parser and has a strict BNF which allows for helpful syntax errors rather than side effects!

During development you can now change your schema without throwing away your database. Instead a schema update compares your current database layout and your current schema changes to update only what is necessary.

The MongoDB ODM shares the same architecture as ORM only with a DocumentManager instead of an EntitiyManager. Its DocumentManager makes full use of the MongoDB API.

You can even remap objects from Document to Entity and back during development and even during runtime. So fetching a model from the database and saving it to MongoDB should be possible.

Currently only MongoDB is supported and there is no support for CouchDB yet.

Finally Doctrines ORM supports class table inheritance but after seen the Propel version of it I have to take deeper look before I’m amazed.

Unit & Functional Tests Fabien Potencier

Symfony 2 switched from lime to PHPUnit 3.5 because of standardisation (top prio as the framework is easier to learn that way). lime at the time was an easy option to PHP testing when unit testing had not yet arrived in the PHP world. By using PHPUnit Symfony can now benefit from yet another community while focussing on the framework and some improvements went back to PHPUnit already.

While this is great in itself it gets better when Fabien shares two best practices.

There should be no more AllTests.php. Instead you can use phpunit.xml (it has a bootstrap attribute!).

Don’t unit test your controllers! Controllers are not unit tested because they should only contain glue code and no business logic.

The functional test framework now has a cleaner API and utilises DomCrawler and Browser components.

Functional tests now only test the response object, which is exactly what you receive then the request is handled by your controller.

You can have multiple instances of the Browser so that you can even test the interaction of multiple clients. Even when you use a library with static states this will work as for each Browser a new PHP process will be created.

Because the functional tests are using the Browser component they can even be run on your production environment for monitoring purposes utilising the profiler of the request. Even testing of non-symfony websites is possible!

The new form framework Bernhard Schussek

After all the experience with the form framework of symfony 1 the new incarnation now got a whole new architecture and was completely redesigned for simplicity and reusability.

“Symfony 2 embraces your domain model”

Validators now validate domain models and forms.

Form fields are fully culture aware (localised) and can be grouped to “lightweight subforms” that become a widget like i.e. a google maps locator widget.

CollectionFields can be used to add lists of fields for 1-n relations.

The form framework is of course also a standalone library that does not depend on without Symfony 2.

Constraints can be added using annotations or XML or Yaml even using callbacks on your models so you can easily implement dynamic constraints.

If forms are now directly modelled on your domain objects then how can you do embedded forms? Well you can’t or at least not as you do in symfony 1. For example if you want to have a form for a user registration based on the user model but with additional fields for terms and conditions or newsletter subscriptions then you have to create a new model Registration first. This may seem like additional effort but if you think about it it makes a lot more sense.

Constraints can also be sequenced i.e. to save on resources when validating cheap constraints first before validating more costly ones that may contain a web service call.

HTML 5 input fields are not yet supported but the forms and validators and fields and everything is fully internationalisationable.

This sounds like something to really look forward to as the forms of symfony 1.2+ were certainly better than previous versions but had a lot of design flaws which make them feel unintuitive.

The Symfony 2 Killer Feature… Fabien Potencier

I was right!

“Caching on the Edge”

According to yet another benchmark test Symfony 2 will be much faster than symfony 1 and even faster with more concurrent requests. All this is caused by the new killer feature: the cache.

Just like Varnish, Squid or Akamai Symfony 2 provides an HTTP cache or reverse proxy implemented in PHP. Symfony 2 also implements the related HTTP specifications and uses the cache headers for controlling the cache behaviour. This means that you can easily replace the PHP cache with Varnish or Akamai without the need to change.

And the cache classes are very easily integrated as they decorate the kernel. They can therefore be activated even for functional tests.

What about when parts of the page must be cached less?

Yes the best bit is still to come. Symfony 2 also implements the Edge Side Include (ESI) specifications written by Akamai which can be used to cache parts of the pages differently from the rest. This is accomplished by the view part of the MVC pattern which can return every partial separately if I understood correctly. You can even use other webpages as partials. Well, I have to digg into this at some point but I am utterly amazed of the completeness of the design.

I can see that it forces you to better separation of concerns as you have to think about your cache times early in the process. Which is good.

To sum it all up: the cache layer is separated from the framework. This does not only mean that you can exchange it with other reverse proxies it only means that for each page request that can be answered by the cache layer the kernel of the framework is not even booted! Symfony 2 also implements stale-while-revalidate and stale-if-error. Go and google it if you don’t know what this is, it is absolutely fantastic!

Another best practice advise:

If you have to think about invalidating the cache then you are most likely using expiration instead of validation. In other words: for dynamic parts you should let the cache validate the cache instead of setting an expire time. Cache validation is soon going to be automatically optimised. I’m curious how this will work.

However great this all sounds for now you have to remember that everything is still experimental.

Conclusion

Well what can I say except that Symfony 2 feels so right on so many levels. This might even have a big impact on the whole PHP community. Can’t wait until it’s stable in 2011!

phpUnderControl 0.6.0beta2 released

2010-06-10T10:25:00+00:00

Today I have released the second beta version of phpUnderControl. Beside several minor tweaks and bug fixes, this release contains one additional feature I was asked for during the IPC in Berlin. This feature allows you to specify a maximum number of log entries that will be shown in the generated metric charts. This can be very useful once you have a project with a great amount of builds and the chart rendering gets slower and slower.

This feature adds a new option --max-number to phpUnderControl's chart command. To rebuild all your charts you can call phpUnderControl's shell script with the following command:

  mapi@arwen ~ $ phpuc --force-update --max-number 42 \
                 /opt/cruisecontrol/logs/phpUnderControl \
                 /opt/cruisecontrol/logs/phpUnderControl

You can get the latest release of phpUnderControl through its pear channel:

  mapi@arwen ~ $ pear upgrade --alldeps phpuc/phpUnderControl-0.6.0beta2
  Starting to download phpUnderControl-0.6.0beta2.tgz (546,314 bytes)
  ...................................................................
  .............................done: 546,314 bytes

or you can get the latest development version on github.

StreamHitching – stream wrapper mini framework alpha version now fully PHPUnit tested

2010-06-08T20:40:54+00:00

As I mentioned before I am working on a small framework to implement custom stream wrappers.

For example you can later use this to easily wrap access to a web service or similar.

As of today I reached a 90+% code coverage and everything passes. Check out the sources and see if some test does not work for you.

I already got the feedback that running Windows there are a few minor issues that I will take care of soon.

The unit tests themselves might not be the easiest on the eye right now but I am getting there. Also the documentation is not yet written.. remember this is still alpha!

So feel free to try and break and contribute by checking out or forking StreamHitching on GitHub.

PHPUnit 3.5 Beta 1

2010-06-08T08:20:00+00:00

To celebrate the 15th birthday of PHP, I have released PHPUnit 3.5 Beta 1 today. The refactoring towards components is a "new feature" that is already visible upon installation:

sb@vmware ~ % pear install phpunit/PHPUnit-beta
phpunit/PHPUnit can optionally use PHP extension "dbus"
downloading PHPUnit-3.5.0beta1.tgz ...
Starting to download PHPUnit-3.5.0beta1.tgz (105,588 bytes)
........................done: 105,588 bytes
downloading DbUnit-1.0.0beta1.tgz ...
Starting to download DbUnit-1.0.0beta1.tgz (38,209 bytes)
...done: 38,209 bytes
downloading File_Iterator-1.2.1.tgz ...
Starting to download File_Iterator-1.2.1.tgz (3,225 bytes)
...done: 3,225 bytes
downloading Text_Template-1.0.0.tgz ...
Starting to download Text_Template-1.0.0.tgz (2,493 bytes)
...done: 2,493 bytes
downloading PHP_CodeCoverage-1.0.0beta1.tgz ...
Starting to download PHP_CodeCoverage-1.0.0beta1.tgz (108,640 bytes)
...done: 108,640 bytes
downloading PHP_Timer-1.0.0.tgz ...
Starting to download PHP_Timer-1.0.0.tgz (2,536 bytes)
...done: 2,536 bytes
downloading PHPUnit_MockObject-1.0.0beta1.tgz ...
Starting to download PHPUnit_MockObject-1.0.0beta1.tgz (15,816 bytes)
...done: 15,816 bytes
downloading PHPUnit_Selenium-1.0.0beta1.tgz ...
Starting to download PHPUnit_Selenium-1.0.0beta1.tgz (15,298 bytes)
...done: 15,298 bytes
downloading PHP_TokenStream-1.0.0beta1.tgz ...
Starting to download PHP_TokenStream-1.0.0beta1.tgz (7,023 bytes)
...done: 7,023 bytes
install ok: channel://pear.phpunit.de/File_Iterator-1.2.1
install ok: channel://pear.phpunit.de/Text_Template-1.0.0
install ok: channel://pear.phpunit.de/PHP_Timer-1.0.0
install ok: channel://pear.phpunit.de/PHP_TokenStream-1.0.0beta1
install ok: channel://pear.phpunit.de/PHP_CodeCoverage-1.0.0beta1
install ok: channel://pear.phpunit.de/PHPUnit-3.5.0beta1
install ok: channel://pear.phpunit.de/DbUnit-1.0.0beta1
install ok: channel://pear.phpunit.de/PHPUnit_MockObject-1.0.0beta1
install ok: channel://pear.phpunit.de/PHPUnit_Selenium-1.0.0beta1

Happy Birthday PHP! And have fun testing (with) PHPUnit 3.5!

How many asserts should a PHPUnit test case have?

2010-06-07T20:28:15+00:00

This question came up in the comments to yesterdays post.

The commenter WC summed it up pretty well I think but I am going to summarise it anyway.

I a lot of best practice books or blog posts you can read that only a single assertion is advised per test case.

The reason is simple.

A test case will return failed as soon as one of its assertions fails. The consequence of this is that any succeeding asserts are no longer executed so you wont know if they pass or fail until you fixed the first assertion.

There are exceptions to this rule though.

I just recently had to test a stream wrapper and one of the methods to test was stream_stat() which is called by PHP in return of calling fstat().

  public function testFstat()
  {
    $fh = fopen($this->url, 'r');
    $stat = fstat($fh);
    $this->assertType(PHPUnit_Framework_Constraint_IsType::TYPE_ARRAY, $stat, 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('dev', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('ino', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('mode', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('nlink', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('uid', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('gid', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('rdev', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('size', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('atime', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('mtime', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('ctime', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('blksize', $stat), 'fstat — Gets information about a file using an open file pointer');
    $this->assertTrue(array_key_exists('blocks', $stat), 'fstat — Gets information about a file using an open file pointer');
    fclose($fh);
  }

This might not be the prettiest test case but you can see a lot of succeeding assertions.

The reason why I think this is a valid exception to the otherwise reasonable rule is that all of these assertions test for a detail of a single operation.
Especially the TYPE_ARRAY test would make no real sense alone it would just blow up the code.

Any thoughts?

Unit testing PHP Stream Wrappers with PHPUnit

2010-06-07T03:10:59+00:00

In the last couple of months I have occupied myself a lot with unit testing. Once you get the hand of it it starts to feel natural and easy and you don’t want to miss it any more. Testing rocks!

Another thing I worked with are PHP streams which IMHO is one of the most underrated features of PHP.

Naturally I want to test my stream wrappers with PHPUnit just as I would test everything else. But it’s not that easy..

When you develop a software component you design it to be used and with your unit tests you simulate this usage as a warranty that your changes to the component won’t break the code using it.

With stream wrappers this becomes a bit tricky as you don’t have an easy access to the code calling your component.

For example you will most likely implement stream_open() which is called internally by fopen() and that’s the difficulty.

This is a part your stream wrapper:

  public function stream_open ( string $path , string $mode , int $options , string &amp;$opened_path )
  {
    ..
    // Returns TRUE on success or FALSE on failure.
  }

And this will be the part of the code using it:

..
$fh = fopen ('yourprotocol://some/path/and/file.name' , 'r', false, $context);
..

Usually I would attempt to test stream_open() with a test like this:

  public function testStreamOpen()
  {
    $wrapper = new MyStreamWrapper();
    $this->assertTrue($wrapper->stream_open('myprotocol://some/path/and/file.name' , 'r'));
  }

But have you noticed that the signatures of stream_open() and fopen() is different after the second parameter?

Somewhere within the C code of PHP the call to fopen() will be implemented and eventually it will make a call to your stream_open(). In the meantime it will have passed the context (which needs to be a public attribute of your stream wrapper and it will calculate some options and an opened path.

Writing a test as I did above will probably work in most cases. But how can you be sure that every possible call to fopen() is working well when you don’t know what happens between the two methods?

You could have a thorough look at the sources of the PHP binary of course and I won’t stop you as this will be an interesting read. But I think an easier approach would be to change the unit test to something like this:

  public function testStreamOpen()
  {
    stream_wrapper_register('myprotocol', 'MyStreamWrapper');
    $this->assertNotFalse(fopen('yourprotocol://some/path/and/file.name' , 'r'));
    $this->assertNotFalse(fopen('yourprotocol://some/path/and/file.name' , 'w'));
    $this->assertNotFalse(fopen('yourprotocol://some/path/and/file.name' , 'r', true));
    $this->assertNotFalse(fopen('yourprotocol://some/path/and/file.name' , 'r', false, stream_context_create(array('yourprotocol'=>array(...)))));
    $this->assertFalse(fopen('yourprotocol://some/path/and/file.name' , 'r', true, stream_context_create(array('yourprotocol'=>array(...)))));
    ..
    stream_wrapper_unregister('myprotocol');
  }

So instead of testing your stream wrappers methods directly you test if all defined usage of your stream wrapper is functioning by calling the appropriate PHP filesystem functions.

In my current case I have a stream wrapper that represents a single read only file. So I wrote tests for each PHP filesystem function that attempts to work on a file assuming that write access fails while read access passes.

Additionally I wrote unit tests calling the stream wrapper methods directly just to make sure.

PHP Temporary Streams

2010-05-29T18:49:03+00:00

It’s been a while since David Sklar called out to let a thousand string concatenations bloom. That discussion produced some entertaining suggestions for putting strings together such as using preg_replace and calling out to MySQL with SELECT CONCAT.

Here’s an approach that uses filesystem functions. When combined with some lesser-known PHP streams functionality, it has several practical applications.

Opening Files for Reading and Writing

There are several modes for opening a file that will allow you to seek to arbitrary positions in the file and read or write at those positions. One of the most frequently used of these modes is w+, which the tmpfile function uses automatically.

We can repeatedly write, then rewind the pointer and read:

$f = tmpfile();
fwrite($f, 'foo');
fwrite($f, 'bar');
 
rewind($f);
$contents = stream_get_contents($f);  //=> "foobar"
fclose($f);

When writing to the filesystem, the above provides yet another inefficient solution to David’s exercise. Now let’s take it a bit further to see how this can be useful.

In-Memory Streams

PHP 5.1 introduced two new in-memory streams: php://memory and php://temp. The php://memory stream operates entirely in memory. The php://temp stream operates in memory until it reaches a given size, then transparently switches to the filesystem.

We can modify the above example to use the php://memory stream instead of hitting the filesystem:

$f = fopen('php://memory', 'w+');
fwrite($f, 'foo');
fwrite($f, 'bar');
 
rewind($f);
$contents = stream_get_contents($f);  //=> "foobar"
fclose($f);

Putting a string inside a fast temporary stream can be very useful. For example, we can then attach filters to that stream.

Testing

Temporary streams are also handy for testing. There are some rather elaborate virtual file system libraries out there but many times a stream is all you need.

Zend_Log has a log handler for streams that accepts either a filename or a stream resource. We can configure it with a php://memory stream for testing:

$f = fopen('php://memory', 'w+');
$writer = new Zend_Log_Writer_Stream($f);
$logger = new Zend_Log($writer);

Assuming your well-designed application has a convenient injection point for the logger instance, your test can pass it in before your test activates some action which should result in logging:

$logger->crit('critical message worth testing');

When the action has completed, the test can rewind $f and use it as a test spy.

rewind($f);
$contents = stream_get_contents($f);
$this->assertRegExp('/message worth testing/i', $contents);  // PHPUnit

Not surprisingly, my unit tests for Zend_Log use this same technique.

Application Usage

Not long ago, we built a custom document storage system for a client. One of its more interesting features is that it integrates with an internet fax service so users can select documents in the system and then fax them. For each fax, the software automatically generates a cover page.

To make the cover page, I first made a nice template using a drawing tool and then saved it in PDF format. I then used Zend_Pdf to write over the template with dynamic content. I first demonstrated this technique in this article.

Since the cover page is only used once (during transmission) and easy to regenerate, I don’t save the output to the filesystem. Instead, I create a php://temp stream. The instance method Zend_Pdf->render() writes the PDF output only to that stream, which is then rewound. Functions like stream_copy_to_stream or fpassthru can then be used to send the final output where it needs to go, and the whole process normally never needs to use the disk.

OSCON 2008 Slides

2010-05-29T18:48:07+00:00

Slides from my two talks at OSCON 2008 are now available:

Both talks were well attended had great audience participation. Thanks to everyone that attended and I hope you enjoyed them.

About seven people came up after the Integration Testing talk with good questions and feedback. I think that 45 minutes was enough to provide good starting points for the topics covered but it was clear that these users were engaged and ready to dig into it more. If I give this talk again, it is going to be in a tutorial format so we can get much deeper into the material and have some exercises.

After my Supervisor talk at the end of the day, I had the pleasure of going out to dinner with Roger Hoover and some other Supervisor users. It’s been very exciting to see Supervisor picking up traction over the past year. Besides the work that Chris McDonough and I are doing, Supervisor is being used in several large architectures of companies whose names you know. If you’re using Supervisor and wouldn’t mind us telling others about it, please contact me.

Speaking at OSCON 2008

2010-05-29T18:47:43+00:00

The OSCON 2008 website has published its talk schedule. I’ll be giving two talks at OSCON this year; one on the Python track and one on the PHP track.

Supervisor as a Platform

I will quickly introduce you to Supervisor and the immediate benefits of running your server processes under it. We will then dive into how applications written specifically for Supervisor can take advantage of it as a platform — writing your own event listeners to observe Supervisor and the process lifecycle, controlling with XML-RPC, and extending the Supervisor core with your own Python extensions.

This will be an expanded version of the talk I gave with Chris McDonough at PyCon 2008. Since PyCon, there’s been quite a few interesting developments in Supervisor like the ability to extend supervisorctl and progress made on configuration reloading. We’ll touch on these as well, so if you attended the PyCon talk there will still be new and interesting material in this talk for you.

Integration Testing PHP Applications

While more PHP developers are recognizing the importance and benefits of unit testing, the uptake of PHP developers using automated integration or acceptance testing is relatively slow. This testing is equally crucial to maintaining the integrity of applications.

I’m going to help get you started testing at the application level with practical tips and source code. We’ll look at how to structure your HTML markup so it’s more easily testable, making tests easier to write and maintain with CSS selectors, organizing your tests, and testing with or without a browser.

We write a lot of PHP applications with this kind of testing at Maintainable. Before the conference, we plan to release some open source PHP code to help you test that we’ll cover in the talk as well. I’d also suggest you check out Sebastian Bergmann’s tutorial session on PHPUnit’s integration with Selenium RC.

Best practice of PHPUnit testing a symfony 1.4 plugin

2010-05-19T11:16:32+00:00

I started this blog to occupy myself with topics like unit testing, continuous integration and code quality in general. As a subject for my studies I quickly released a symfony plugin (sfImageTransformExtraPlugin) that I already worked on for a while and decided to excercise all my learnings on it. So you can peek at the sources to see more details.

As all the early posts of this blog were kept in German I am going to summarise the best practice of PHPUnit testing a symfony 1.4 plugin in this post.

Of course I have to say that the term best practice refers to my current state of knowledge.

Why PHPUnit?

Actually when I started this blog I was determined to use symfonys own lime unit test implementation because it is integrated and documented within the symfony documentation. But the more I worked with it the more I was put off by it.

lime is ok for being run during development by the developer itself but it can not easily be used in continuous integration as it is not fully xUnit compliant and does not provide all infos you want to see there. lime is also very procedual and the more complex your application become the more spaghetti code you will have to maintain. And foremost lime is only used in the symfony world and learning it will not have any benefit for you in other projects.

PHPUnit on the other hand is the de facto standard for PHP. It is object oriented as well as well documented and maintained and it is fully xUnit compliant thus can easily be integrated into your continuous integration workflow.

Prerequisites / Assumptions about your plugin

In the following I assume that you generated your plugin by running the symfony task generate:plugin (provided by sfTaskExtraPlugin) and that you did not change the files and directories inside your plugins /test directory.

This is important as there are many files that were generated for you that may look curious to you but will make a lot more sense once you learned how to use them.

Of course these files were created with lime in mind and in the following I will show you what you need to change to use the same structure with PHPUnit.

Bootstrapping

In your plugins /test/bootstrap you will find a script for bootstrapping for your unit tests unit.php.

// /plugins/myTestPlugin/test/bootstrap/unit.php
<?php
 
if (!isset($_SERVER['SYMFONY']))
{
  throw new RuntimeException('Could not find symfony core libraries.');
}
 
require_once $_SERVER['SYMFONY'].'/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
$configuration = new sfProjectConfiguration(dirname(__FILE__).'/../fixtures/project');
require_once $configuration->getSymfonyLibDir().'/vendor/lime/lime.php';
 
function myTestPlugin_autoload_again($class)
{
  $autoload = sfSimpleAutoload::getInstance();
  $autoload->reload();
  return $autoload->autoload($class);
}
spl_autoload_register('myTestPlugin_autoload_again');
 
if (file_exists($config = dirname(__FILE__).'/../../config/myTestPluginConfiguration.class.php'))
{
  require_once $config;
  $plugin_configuration = new myTestPluginConfiguration($configuration, dirname(__FILE__).'/../..', 'myTestPlugin');
}
else
{
  $plugin_configuration = new sfPluginConfigurationGeneric($configuration, dirname(__FILE__).'/../..', 'myTestPlugin');
}

There are two things to notice here:

The use of $_SERVER['SYMFONY']

When executing unit tests you have to tell the bootstrap where to look for the symfony core libraries. For lime this is actually done by the symfony test tasks but for PHPUnit we don’t have a task available so we need to run the following command first (only once per console session).

$ export SYMFONY="/absolute/path/to/lib/vendor/symfony/lib"

I will explain the reason behind this in a moment.

The project configuration is looaded from a fixture project

If you have a look at your plugins /test/fixtures/project directory you will recognise a complete symfony project just like you run generate:project.

This is going to be your test environment.

The reason for both of these two features is this:

The whole point of a symfony plugin is to be reusable and to be reusable it needs to be as project independant as possible.
Therefor it will not be unit testet in a project where the project developers can easily create situations where your tests will fail but in a fixture project you as a plugin developer can completely control.

And because this fixture project is included in your project we don’t want to also include the whole symfony code.
But a symfony plugin will always have at least one dependancy and that is towards symfony itself, so we have to make the location of it known to our plugin before running the tests.

Now for PHPUnit we need to remove the following line from the code above.

13	require_once $configuration->getSymfonyLibDir().'/vendor/lime/lime.php';

The purpose of this bootstrap file is to create the environment our plugin expects. So if all of your plugins functionalities need an instance of sfContext you would create it here or if they would all depend on the database you would create a connection here as well.

But remember there should be as few dependencies as possible!

How to write your test cases?

This is the easies part of all. Just refer to the PHPUnit documentation and see how to write the tests themselves and add everything to classes like this:

// /test/unit/lib/yourPluginClassTest.php
<?php
require_once dirname(__FILE__).'/../bootstrap/unit.php';
require_once 'PHPUnit/Framework.php';
 
class yourPluginClassTest extends PHPUnit_Framework_TestCase
{
  public function testYourMethod()
  {
    // .. implement your test here
  }
}

The above example will test your method yourPluginClass::yourMethod() so you see the conventions of appending “Test” to the class and prepending “test” to the methods your going to test.

I found it a good practice to organise my test cases the same way as the tested classes.

For example:
/lib/routing/yourOwnRoute.class.php (classname: yourOwnRoute)
would be tested in:
/test/unit/lib/routing/yourOwnRouteTest.php (classname: yourOwnRouteTest)

Another good practice is to have one test case per class so each of your classes has exactly one test class.

You can run your test case like this.

$ phpunit /test/unit/lib/routing/yourOwnRouteTest.php

How to write a test suite?

Often you want to run all your test cases at once. In fact for continuous integration purposes this is always the case. This can be achieved using a PHPUnit test suite that can run multiple test cases.

A good naming convention is to create such a suite in the /test directory of your plugin and to call it like you called you plugin.

// /test/yourPluginTests.php
<?php
class yourPluginTests
{
  public static function suite()
  {
    global $configuration, $plugin_configuration;
    $suite = new PHPUnit_Framework_TestSuite('yourPlugin');
 
    // loading plugin configurations
    $configuration = ProjectConfiguration::getActive();
    $pluginConfig = $configuration->getPluginConfiguration('yourPlugin');
 
    // instantiate a fake symfony unit test task to retrieve all connected tests for this plugin
    $task = new sfTestUnitTask($configuration->getEventDispatcher(), new sfFormatter());
    $event = new sfEvent($task, 'task.test.filter_test_files', array('arguments' => array('name' => array()), 'options' => array()));
    $files = $pluginConfig->filterTestFiles($event, array());
    $suite->addTestFiles($files);
 
    return $suite;
  }
}

In this example I collected all test cases from the fixture project just like the symfony test task for lime does it. This is very convenient as you don’t have to manually add new test cases. Refer to the AllTests section of the PHPUnit documentation for further details of a test suite.

Next we need to make all our test cases known to the fixture project by editing the ProjectConfiguration class.

// taken from http://trac.symfony-project.org/browser/plugins/sfImageTransformExtraPlugin/trunk/test/fixtures/project/config/ProjectConfiguration.class.php
<?php
class ProjectConfiguration extends sfProjectConfiguration
{
  // ...
 
  public function setupPlugins()
  {
    $this->pluginConfigurations['sfImageTransformExtraPlugin']->connectTests();
  }
}

Now you can run all your test cases like this.

$ phpunit /test/yourPluginTests.php

The fixture project

I already mentioned the dependency towards symfony but there is more. There is also the dependency of your plugin towards being properly installed.
This dependency has to be reflected in the fixture project.

For example if you have any schema defined for Doctrine or Propel then the classes generated from these schema will be generated outside your plugin except for the classes prefixed with “Plugin”. So you have to create these generated classes inside of the fixture project as well.
Make sure not to modify these classes they have to be absolutely pristine!

If your plugin needs an application youn have to create one in the fixtrue project and if certain settings in the app.yml or setting.yml or elsewhere are mandatory you will have to create them in the fixture project as well.

Just be aware that you don’t try to fix anything by only adding more to the fixture project. There should be as few changes to it as possible and all changes you have made should be properly documented as they are necessary for anybody who wants to use your plugin.

Dependencies to other plugins

Sometimes your plugin will depend on the existence of other plugins. For sfImageTransformExtraPlugin this was the case as it required sfImageTransformPlugin to be installed. In your fixture project this can be solved by editing the ProjectConfiguration class.

// taken from http://trac.symfony-project.org/browser/plugins/sfImageTransformExtraPlugin/trunk/test/fixtures/project/config/ProjectConfiguration.class.php
<?php
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->setPlugins(array('sfImageTransformExtraPlugin', 'sfImageTransformPlugin', 'sfDoctrinePlugin'));
 
    $this->setPluginPath('sfImageTransformExtraPlugin', dirname(__FILE__).'/../../../..');
    $this->setPluginPath('sfImageTransformPlugin', dirname(__FILE__).'/../../../../../sfImageTransformPlugin');
  }
 
  // ...
}

This expects sfImageTransformPlugin to be located right next to sfImageTransformExtraPlugin which comes in handy if integrated with continuous integration services.

What to test?

For quite some time I kept asking this question. My answer is this:

Don’t test module code! Module code in this case means actions or components. They have far too many dependencies in symfony 1.x and they should be very slim anyway. Test them with functional tests.
Don’t test tests! This should be self explaining really..
Test everything else! This leaves you with the /lib and /config folders only.

And to keep a good overview you should create a coverage report from time to time. Using the following configuration file I use to create mine.

<?xml version="1.0" encoding="UTF-8"?>
 
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         colors="false"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false"
         syntaxCheck="false">
 
  <testsuites>
    <testsuite name="yourPlugin Suite">
      <directory>./test/unit/</directory>
    </testsuite>
  </testsuites>
 
  <filter>
    <whitelist addUncoveredFilesFromWhitelist="true">
      <directory suffix=".class.php">./lib/</directory>
      <directory suffix=".class.php">./config/</directory>
    </whitelist>
  </filter>
</phpunit>

Change into the root directory of your plugin to execute phpunit other wise the relative paths will not work as they are relative to the execution dir not the configuration file!

Conclusion

PHPUnit testing of symfony plugins is tricky as it is not documented anywhere. But it is still very possible and once you got the hang of it feels very natural.

I hope this will help some of you t get started.

Things like mocking database connections or all the hazzle with sfContext might be subject to another post.

PHP-Magazin Artikel zum Thema Softwaremetriken

2010-05-12T07:04:12+00:00

This blog post is in German as the mentioned article was published in German.

In der heute erschienenen Ausgabe 4.10 des PHP Magazins ist auch ein Artikel von mir enthalten, und wie sollte es wohl anders sein *Trommelwirbel*, beschäftigt der sich mit dem Thema Softwaremetriken In diesem Artikel gibt es eine sehr ausführliche Einführung in die Thematik, mit eine Reihe von praktischen Beispielen und den daraus ableitbaren Aussagen über den untersuchten Quelltext.

Über Kommentare, Anregungen und Kritik rund um den Artikel würde ich mich sehr freuen. Und sollte euch der Artikel gefallen haben, empfehle ich die Internationale PHP Conference 2010, die vom 30. Mai bis 2. Juni in Berlin stattfindet, an der ich teilnehmen und zwei Vorträge halten werden.

Artikel zum Thema Softwaremetriken

2010-05-12T07:04:12+00:00

This blog post is in German as the mentioned article was published in German.

Preorder the PHP QA Book now

2010-05-09T08:43:00+00:00

You may want to preorder the PHP QA Book now!

German Edition:

Softwarequalität in PHP-Projekten @ amazon.de

English Edition:

Running PHPUnit tests for your symfony plugin in Hudson

2010-05-04T07:01:46+00:00

Yesterday I wrote about setting up a symfony plugin project in phpUnderControl. However so far I’ve been using Hudson as my Continuous Integration server. So before comparing the two I will explain how to achieve yesterdays setup using Hudson.I assume that you have a running Hudson installation ready.

Hudson is – as you will notice – a web dialog driven tool. You can of course edit the underlying configuration files (mostly XML) but I never experienced the need as the web interface is just as powerful.

Creating the project

In Hudson projects are called jobs. You create one by clicking on “New Job“.

Hudson dialog: New Job

What we want is a free-style software project.

This will directly lead us to the Job Configuration dialog.

Checking out the sources

In the Source Code Management section of the Job Configuration dialog we select Subversion for our version control system (There is a Git plugin for Hudson available) and configure the three sources for symfony, sfImageTransformPlugin and sfImageTransformExtraPlugin.