There’s an old blog post about creating an symfony iPhone view:
http://www.symfony-project.org/blog/2008/06/09/how-to-create-an-optimized-version-of-your-website-for-the-iphone-in-symfony-1-1
Most of it is still valid and it works.

But there is one serious drawback: You have to provide a mobile template for each action.
That’s why we created a tiny patch to provide a fallback to normal templates in case there is no special mobile one.

Here are the required parts:

Mobile detection: This belongs into your project configuration:
http://trac.ullright.org/browser/trunk/plugins/ullCorePlugin/config/ullCorePluginConfiguration.class.php

Symfony patch enabling fallback to html templates: (Patches sfView.class.php)
http://trac.ullright.org/browser/trunk/plugins/ullCorePlugin/patch/sfView.patch.txt

Finally provide a mobile template (or not):
Normaly you would put your template in apps/frontend/modules/myModule/templates/myActionSuccess.php
Now you can provide a mobile template by creating the following file: apps/frontend/modules/myModule/templates/myActionSuccess.mobile.php

This also works for layouts, partials and components. Example: apps/frontend/modules/myModule/templates/_head.mobile.php

Here’s the original post: http://groups.google.com/group/symfony-users/browse_thread/thread/9da0a9fe3cf3ff77

Have a nice day!

No related posts.

Test Balance

The more tests you have for your application, the more difficult it becomes to introduce changes. Everytime you change an existing feature, you have to change at least one test. Everytime you make a refactoring of your project’s architecture (which you should do frequently), you most likely need to adapt multiple tests. As a rule of thumb you can say that the more tests you have, the more difficult it becomes to make changes in your code.

We know that not to write tests is not a solution. Lots of tests, on the other hand, are bad for maintainability. Instead, try to keep a certain test balance by testing only what is important. The following section shows you one possible approach for identifying important tests called risk-based testing.

Risk-Based Testing

The purpose of testing is to avoid regressions in your software resulting of its complexity. These potential regressions can be expressed as risks ranked by their probability and severity. The probability expresses how likely the regression is to occur. The severity expresses how severely the regression would affect the functionality of your application. Both can be expressed in numbers, for instance in a range of 1 to 10 with 10 being the highest severity/probability. Look at the following table for example:

The table contains risks for two fictitious methods getGroup() and calculatePrice(). Imagine that the first of these methods only returns an internal property $group. The probability of someone breaking this code by accident is near to non-existent. Assume further that the group is only used for display purposes, so the severity of a broken code is not very high either.

The second method, calculatePrice(), uses an internal algorithm to calculate the price of a product. Because it depends on an external object $product, and because the algorithm is non-trivial, the probability of breaking the code is rather high. Even higher though is the severity of a broken functionality – what could be worse than wrongly calculated prices.

Is it worth to unit-test getGroup()? Probably not. We calculated an overall total of 3, which (in our scale from 1 to 100) is really not that impressive. Is it, on the other hand, worth to test calculatePrice()? Judge for yourself.

Obviously I selected two extreme examples here. Also you will almost never calculate probabilities and severities for testing single methods like I did it here. But you should try to develop a feeling for what is worth to be tested and what is not.

Test Complexity

Now that you have identified which risks you should cover in your test suite, the question is to what extent you should do so. Look at the following to approaches for testing calculatePrice():

Approach 1: The fair-enough approach

$t = new LimeTest();
 
// @Test: calculatePrice() multiplies the price with the amount
 
  $product = new Product();
  $product->price = 100;
  $product->amount = 2;
  $t->is($calculator->calculatePrice($product), 200);

Approach 2: The safe approach

$t = new LimeTest();
 
// @Before
 
  $product = new Product();
  $product->price = 100;
 
// @Test: calculatePrice() multiplies the price with the amount (amount == 1)
 
  $product->amount = 1;
  $t->is($calculator->calculatePrice($product), 100);
 
// @Test: calculatePrice() multiplies the price with the amount (amount == 2)
 
  $product->amount = 2;
  $t->is($calculator->calculatePrice($product), 200);

The first approach assumes that testing whether the result equals price multiplied by amount is enough. The test can obviously not check whether the developer has hard-coded a fixed return value of 200 or uses a fixed amount of 2. It expects the developer to be reasonable.

The second approach takes care of these eventualities by writing another test to make sure that changed amounts result in changed outputs. But even now, the developer could write a simple switch statement in calculatePrice() and return either 100 or 200, based on the amount. The test will not notice.

The conclusion is that you can never test your code for all eventualities. However complicated your test may be, there will always be a way to fake the implementation. But is it likely that developers will fake it? Probably not. This being said, the best approach in my opinion is approach 1 because it keeps effort required to adapt or change the test to a minimum.

Conclusion

Don’t try to achieve 100% test coverage. Identify the most important risks, and test for those. Don’t test for all eventualities either. Always keep in mind that the developers working on your code are somewhat reasonable people. If they aren’t, you are probably better off without them anyway.

No related posts.

What happened?

Unit vs. System Tests

To begin with, you need to understand the difference between unit and system tests and the impact both have on testing performance.

Unit tests are atomic. They test classes and components in isolation from any other service they depend on. Such services can be external services, like mailing systems, databases or webservices, and internal services, like a calculator, a data store or similar service classes. Running these tests in isolation gives you several advantages:

• Speed of execution
• Speed of development
• Test confidence

Speed of execution, because the test doesn’t need to wait for the related service to process its internal logic. Speed of development, because you (hopefully) don’t have to adapt the test when you refactor the internals of the related service class or add new features to it. And test confidence, because the test will only fail when the tested class is erroneous, not if any of the related services provide wrong data.

System tests (acceptance or functional tests are a kind of system tests) test whether all the classes in your application collaborate correctly. Because you unit tested these classes in isolation, you had to assume how collaborating services should behave. If this assumption is wrong, no unit test will tell you. And that’s the space that system tests fill. The big, big disadavantage of system tests is that they are slow. They have to initialize the application, read its configuration files, initialize its database with fresh data (it doesn’t make a lot of sense to disconnect system tests from the real database) and more. All this takes time.

The conclusion from the last paragraphs is that features of your application should always be tested in unit tests. These tests are fast and guide you to the error if things go wrong. There is nothing more harmful to test performance than testing whether a form works correctly by means of a system test. If the form is a class, write a unit test. If the form is no class, make it one.

Decouple Your Code

If you reach the point that you have lots of unit tests and few system tests, you made the first step towards becoming a test speed king. The second step is to decouple your classes.

Highly coupled code negatively affects your development in several ways. Because your code depends on other classes, these other classes (the dependent-on components or DOCs) all have to be instantiated during testing. Depending on their nature, this process may take time and slow your test down. Introducing new features becomes difficult because it results in lot of test code that needs to be adapted. If one of your classes breaks, not only the test of the class fails, but also several other tests of dependent classes. Shortly spoken: Extending and maintaining the application becomes a nightmare.

To decouple your code, get a clear picture of the responsibilities inside of your application. If a class does too much, tear it apart like a wild monkey smelling a banana in a big pile of waste paper.

The following code samples are based on the PHP5 frameworks symfony, Doctrine and Lime 2. The same concepts can be applied to other frameworks and languages just as well.

Let’s look at a (slightly modified) example I recently saw in a code review:

class sfValidatorUsername
{
  public function clean($value)
  {
    $user = Doctrine_Query::create()
      ->from('User u')
      ->where('u.name = ? AND u.active = 1', $value)
      ->fetchOne();
 
    if (is_null($user))
    {
      throw new sfValidatorError('invalid', $this);
    }
 
    return $value;
  }
}

It should be pretty obvious what this code is doing. What is the problem? The validator depends on the database. This is not a problem per se, but querying the database for User objects is beyond the validator’s responsibilities. This task should rather be done by your data acccess objects (DAOs), entity stores, tables or whatever you call them. And these objects can easily be injected into the validator using Dependency Injection.

Happy that we have identified this code smell, we can already start removing it:

class sfValidatorUsername
{
  protected $table;
 
  public function __construct(UserTable $table)
  {
    $this->table = $table;
  }
 
  public function clean($value)
  {
    if (is_null($this->table->findActive($value))
    {
      throw new sfValidatorError('invalid', $this);
    }
 
    return $value;
  }
}

We removed the database code and instead inject the table object into the constructor. The responsibility for fetching an active user by its name was outsourced to the table.

An even faster solution is to only count the matching user objects in the database instead of querying and hydrating them. But that’s not in the scope of this article.

So, mummy, is our test faster already? Is it?

Replace Dependencies During Testing

No, kid. We are still using the UserTable when testing the validator – of course, because we need it. So what can we do?

Now that the validator only depends on the UserTable, and not on some mystical database query magic, we can replace the UserTable – which is tested somewhere else and assumed to be working – with a fake implementation. This is usually called stubbing (because you are replacing it with a non-functional stub). With Lime 2, you can do it like this:

$t = new LimeTest();
 
// @Test: clean() returns the cleaned value if the user is found
 
  $table = $t->stub('UserTable');
  $table->findActive('bob')->returns(new User());
  $table->replay();
  $validator = new sfValidatorUsername($table);
 
  $t->is($validator->clean('bob'), 'bob');

The stub acts as if it was the real UserTable object, but in reality it has no internal logic at all. So compared to the real table, the stub is very fast.

More documentation about Lime 2 and its stubbing/mocking capabilities can currently be found on the Lime 2 GitHub repository.

A word of caution shall be spoken. You should only replace services (classes that process some data and return a result) with stubs, not entities (classes that simply contain data). Otherwise changing your domain model (the entities) will soon become a nightmare.

Testing With Databases

Hurray! The validator test is so fast, I can execute it 10 times in a row and it’s still fun. One more time! Nice.

But wait – we can’t decouple everything from the database, can we? Of course, we can’t. Code that is responsible for collaborating with the database, like the above UserTable, needs to access the database. In order for that test to work, the database has to be bootstrapped and filled with data. Because tests should run in isolation from each other, the database further needs to be reset before every single test.

Now a common mistake that severely affects testing performance can often be seen in symfony projects. Many developers use a test database on their development DBMS, like a MySQL server. This database is filled with the content of fixtures.yml, which usually contains all fixture data commonly used to test the application in the browser. And for good reasons this is very slow:

• Most DBMS store data on the file system. Hard disk access is an expensive operation.
• Filling the database with all the test data takes a lot of time
• Parsing YAML files is slow

So ideally we don’t use the database and don’t use any test data. Obviously, that’s not possible.

In-Memory Databases

What is possible is to use an in-memory database. While CPU access on the hard disk usually takes around 4 170 000 ns (nano seconds) for 7200 RPM drives, memory access only takes around 14 ns! Thus, using an in-memory database is a very cheap way to increase your testing performance immensely. Unfortunately not all database vendors offer in-memory alternatives for their file-based DBMS (such as MySQL). In such cases I use SQLite in-memory databases, because SQLite supports most of the SQL92 standard, which is generally sufficient for testing purposes.

If you use symfony with Doctrine, you can place the following code snippet into your bootstrap/unit.php file which initializes the SQLite in-memory database:

// initialize Doctrine
$cacheFile = sprintf('sf_autoload_unit_doctrine_%s.data', md5(__FILE__));
$autoload = sfSimpleAutoload::getInstance(sys_get_temp_dir().'/'.$cacheFile);
$autoload->addDirectory(ROOT_DIR.'/lib/model');
$autoload->addDirectory(ROOT_DIR.'/lib/form');
$autoload->addDirectory(ROOT_DIR.'/lib/filter');
$autoload->register();
 
$database = new sfDoctrineDatabase(array(
  'name' => 'doctrine',
  'dsn' => 'sqlite::memory:'
));
 
// load all missing model files
Doctrine::loadModels(ROOT_DIR.'/lib/model');
 
/**
 * Reloads the database.
 */
function reload()
{
  // close the connection to the in-memory database to recreate the database
  Doctrine_Manager::getInstance()->getCurrentConnection()->close();
 
  // create the database tables from the loaded models
  Doctrine::createTablesFromModels();
 
  // clear the Doctrine cache
  foreach (Doctrine::getLoadedModels() as $model)
  {
    Doctrine::getTable($model)->clear();
  }
}

Make sure the constant ROOT_DIR is defined and points to the root of the tested project (your real project or the fixture project).

You might wonder why the $cacheFile is required. This parameter allows us to run multiple tests in parallel while still leveraging autoloading performance by using a cache.

The real interesting piece of code is the reload() function. It allows you to recreate the database on demand. Whenever you write a test that requires a fresh database, call reload() and you are good to go.

Fixture Management

As described above, it is important to keep an eye on the test data that is loaded into your database. The more data you load, the more time it takes. Loading the whole fixtures.yml is a recipe for slow (not only because it contains a lot of data, but also because the YAML file must be parsed).

A much more efficient solution is to programmatively create and load test data on-the-fly. Only create what you need, and nothing more. Below you can find a sample test for our above method UserTable::findActive():

$t = new LimeTest();
 
// @Test: findActive() returns an active user by username
 
  reload();
  $user = new User();
  $user->username = 'bob';
  $user->active = true;
  $user->save();
  $table = Doctrine::getTable('User');
  $t->is($table->findActive('bob'), $user);

This test is really fast now. The database is created in-memory, exactly one single User object is inserted and that’s it. The downside is that creating all the fixture data inline becomes a little messy, especially if you have to fill a lot of properties only because they are defined as NOT NULL in the database.

Creation Methods

To work around this issue, I prefer the Creation Method pattern by Gerard Meszaros[1]:

We should use a Creation Method whenever consructing a Fresh Fixture requires significant complexity and we value Tests as Documentation.

The pattern is very simple. Encapsulate the code required to create an object within a utility function that can be reused across your project. My rule of thumb is to write creation methods for all tested Doctrine records and initialize all NOT NULL fields and relations with default values so that the object can be saved without further modification. Because this leads to a lot of code duplication, I also use a base function createObject().

function createUser(array $properties = array())
{
  return createObject('User', $properties, array(
    // NOT NULL properties
    'username' => 'francis',
    ...
    // NOT NULL relations
    'Group' => createGroup(),
    ...
  );
}
 
function createObject($class, array $properties, array $defaultProperties)
{
  $properties = array_merge($defaultProperties, $properties);
 
  $object = new $class();
  foreach ($properties as $property => $value)
  {
    $object->set($property, $value);
  }
 
  return $object;
}

Now you can call createUser() everytime you need to create and save a new User object. Optionally, you can inject property values into the constructor.

$t = new LimeTest();
 
// @Test: findActive() returns an active user by username
 
  reload();
  $user = createUser(array(
    'username' => 'bob',
    'active' => true,
  ));
  $user->save();
  $table = Doctrine::getTable('User');
  $t->is($table->findActive('bob'), $user);

/**
 * Saves all objects passed as arguments.
 * @param Doctrine_Record $object1
 * @param Doctrine_Record ...
 */
function save()
{
  foreach (func_get_args() as $object)
  {
    $object->save();
  }
}
 
/**
 * Creates a collection containing the passed objects.
 * @param Doctrine_Record $object1
 * @param Doctrine_Record ...
 */
function collection()
{
  if (func_num_args() == 0)
  {
    throw new LogicException('You must pass at least one object');
  }
 
  $objects = func_get_args();
  $collection = new Doctrine_Collection(get_class($objects[0]));
  foreach ($objects as $object)
  {
    $collection->add($object);
  }
 
  return $collection;
}

$user1 = createUser();
$user2 = createUser();
$user3 = createUser();
save($user1, $user2, $user3);
 
$coll = collection($user1, $user3);
// etc.

Pulling All Levers

Now that we have optimized our test code to the highest degree, there is one last thing we can do: Increase the hardware power of the test computers and optimize the test suite to utilize its power.

Because most CPUs nowadays feature multiple cores, you should design your test suite for parallel processing. Make sure that no two tests are using the same resources (another benefit of the in-memory databases) and use a testing framework of your choice that supports multiprocessing.

Lime 2, for example, supports multiprocessing by adding the --processes option:

$ php lime --processes=16

While most of my CPU cores are pretty bored when running the test suite in one process, using multiple processes sparks a sudden increase in activity. Not only that, I could record speed increases of over 300% (15 minutes in one process, 4.5 minutes in 16 processes).

Conclusion

As I have tried to portray in this article, writing tests alone is not enough to improve your development. If tests are slow or prevent change, your developers won’t run and use them. Fortunately there are several ways to make changes easier and to increase test speed.

To summarize:

1. Test single features in unit tests. System tests should only be used to verify whether the classes collaborate correctly within different processes.
2. Decouple your classes. This allows introduction of changes without having to adapt multiple tests.
3. Only classes that really need to should deal with remote services. Replace these classes with stubs in all other tests.
4. Choose the fastest version of a remote service available. When you test database classes, use in-memory databases.
5. Only create databases during testing when you really need them
6. Only load data into the database that you really need. Do so programmatively without taking the overhead of parsing XML or YAML files.
7. Make use of multiprocessing, if supported by your testing framework.

How is your testing experience? Are you satisfied with the performance of your tests?

References

[1] Gerard Meszaros: xUnit Test Patterns. Refactoring Test Code. Addison-Wesley, 2007. Page 415

No related posts.

The “default” context does not exist.

Is there any symfony developer out there who never stumbled upon this dreadful error message? I doubt it. Recently, a lot of posts have been made on the user mailing list asking for explanations and fixes. A quick search on Google for the exact phrase even returns 480 results!

The reason for this error is quite simple though: It’s because you used sfContext::getInstance(). And you should never do that.

MVC and the Context

The class sfContext is the glue of the controller layer in symfony. It keeps all the relevant controller classes together: sfUser, sfResponse, sfRequest, sfController as well as some others. The reason for its existence is simplicity. These classes now only need a reference to the context to access each other. The class sfController, for instance, contains a protected member variable $context, by which it can access all the other objects without having to store seperate references.

sfContext implements the Singleton design pattern. Thus you can retrieve one of the few context instances by calling sfContext::getInstance() with an optional first parameter: The name of the context. If the first parameter is not given, the name is assumed to be “default”. But sfContext is no real Singleton. No new instance will ever be created when you call sfContext::getInstance(). Instead, you need to call sfContext::createInstance() first. If you miss to do that, you will receive exactly the error at the introduction of my post.

Why to Avoid Singletons

The Singleton pattern is actually one of the worst design patterns by the Gang-of-Four[1]. Because you hard-code the name of the singleton class, you create a dependency that is hard and partially impossible to substitute from outside. As a result, your class becomes unflexible and very hard to unit-test. Let’s look at a common mistake:

class Product
{
  public function save()
  {
    if (sfContext::getInstance()->getUser()->hasAttribute('foobar'))
    {
      // do something
    }
  }
}

Listing 1

This implementation bears the following problems:

Problem #1: Flexibility

If you have multiple sfUser instances, you are not able to tell the product on which instance it should depend. The product always fetches the instance registered in the context. Also, if the context is not available (for instance in console tasks), the save() method fails.

Problem #2: Testability

For testing the Product class, you have to create the context including all of its dependencies. That means parsing factories.yml, reading the configuration files, instantiating sfController, sfRequest and many more classes. Doing so adds substantial overhead to your tests and makes them slow and prone to errors. If any of the operations during the context instantiation fails, your Product test will suddenly fail, even if the class Product is perfectly fine!

How to Avoid Singletons

Instead of hard-coding the call to sfContext::getInstance(), you should pass the context object directly to the object that needs it. If you don’t even need the context, but only one of its references like the user, pass that object instead.

class Product
{
  protected $user = null;
 
  protected function setUser(sfUser $user)
  {
    $this->user = $user;
  }
 
  public function save()
  {
    if ($this->user instanceof sfUser && $this->user->hasAttribute('foobar'))
    {
      // do something
    }
  }
}

Listing 2

This technique is called Dependency Injection. If you are not familiar with Dependency Injection, I recommend you to read Fabien Potencier’s introduction to Dependency Injection. Basically there are two ways two inject dependencies into an object:

Constructor Injection

This type of Dependency Injection is used when a dependency is required. Because the dependency needs to be passed in the constructor, no object can ever be created when this dependency is not fulfilled.

class Product
{
  protected $user = null;
 
  protected function __construct(sfUser $user)
  {
    $this->user = $user;
  }
}

Listing 3

Setter Injection

This type of Dependency Injection is used when a dependency is optional. Because you can never be sure whether the setter has been called, you always have to verify whether the object exists before accessing its operations and properties, as we did in Listing 2.

Alternatively, you can also use setter injection for required dependencies if you can not override the constructor without breaking the class (this is the case for Doctrine records). In that case, you simply throw an exception if the dependency is not available.

class Product
{
  public function save()
  {
    if (!$this->user instanceof sfUser)
    {
      throw new LogicException('The user must be set before saving');
    }
  }
}

Listing 4

What You Gained

Because you can now inject any user object into your class, you can test the Product class very easily:

class StubUser extends sfUser
{
  public function hasAttribute($name)
  {
    return $name == 'foobar';
  }
}
 
$t->comment('Products with the attribute "foobar" do something special upon saving');
 
  $p = new Product();
  $p->setUser(new StubUser());
  $p->save();
  $t->is(...);

Listing 5

Exceptions

In very few cases, you cannot avoid accessing the context by using sfContext::getInstance(). This is almost always the case when symfony manages the construction of an object. If you configure symfony to use a custom object by modifying factories.yml, you still won’t be able to inject custom objects.

This will change as soon as symfony uses the new Dependency Injection container for the construction of the core classes.

An example for this problem is extending sfResponse. You can tell symfony to use a custom response, but you cannot tell symfony to inject the context or other objects into it (except for if you write a custom sfFactoryConfigHandler). In this case, and because sfResponse is part of the controller layer, you should be pragmatic and just use sfContext::getInstance().

Conclusion

Always try to avoid calling sfContext::getInstance(). Many of symfony’s classes in the controller layer already store a reference to the context, so you can use that one instead. If no reference is available, inject the reference to the context or to whichever class you need.

References

[1] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995

No related posts.