Another requirement was to be able to build campaign and SEO landing pages that redirect to and article or search result or whatsit.

As a result of just a few hours of writing routing related code there is now a new kid in town: gjShortUrlPlugin.

The functionality of the plugin is very simple.

Every symfony route object implements a method called matchesUrl() which tries to match the URL pattern from the routing.yml on the current URL.

In gjShortUrlPlugin this method looks up a database table to do the matching. All methods to do the matching are atomic and easy to override.

The actual redirection is performed by a symfony module action controller which again gives you every opportunity to override.

Using the admin generator you can easily generate an admin tool to maintain your redirections.

In the README I have listed a few basic examples that should illustrate the flexibility of the plugin and gives you ideas on how to achieve your goals with it.

If anyone cares to write a Propel route I would be glad to add it to the plugin as an alternative option.

I hope this proves useful to someone out there.

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.

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().