naji-dev

Everytime i write unit or functional tests in symfony, i have following problem:

Sometimes my tests do not run deterministically because previous ran tests created data, which intefere with following tests. For example (a simple, not really smart one) think of a system which knows one (and only one) user. For my DAL i would test a method like “createUser” or something. Later on i would create a functional test for a registration form. Now the correctness of the tests depend on the sequence, i run the tests. But this should not be this way! Every time i run a test, i have to know the data before i run a part of my software and i have to know how my software manipulates the data (speaking of the date after running my software). The only way i knew to ensure this state, was to run build-all-reload (as in Symfony 1.2 with Doctrine as ORM) to get a fresh database with the predefined fixtures.

Any software you develop will enlarge, and so the tests will, too. After a time you will get to the point, where you can not run a build-all-reload after each test for some reasons. So how about clearing the database before a test runs like the following?

1
2
3
4
5
6

$browser = new ndTestFunctionalDoctrine(new sfBrowser());
 
$browser->
  reloadData()->
  info('1 - Make a test on a clean database with defined fixtures only')
;

This is what ndTestFunctionalDoctrine offers to test-writing symfony-developers. The only thing you have to handle is: Run reloadData() in your code each time you run a test, which does not depend on the test direct before the current.

Like for functional tests i have a small helper, which can be put to the end of test/bootstrap/unit.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

new sfDatabaseManager($configuration);
 
// helper
function reloadData()
{
  // try to drop the database (an exception is thrown,
  // when the database does not exist)
  try
  {
    Doctrine::dropDatabases();
  }
  catch (Exception $e){ }
 
  // create database
  Doctrine::createDatabases();
 
  // create tables
  Doctrine::createTablesFromModels(sfConfig::get('sf_lib_dir') . '/model');
 
  // load fixtures
  Doctrine::loadData(sfConfig::get('sf_data_dir') . '/fixtures');
}

Analog to this, a version for propel could be build if doctrine is not the ORM of your choice.

Da die Installation mit Hilfe von PEAR nur eine einzige Version von Symfony zulässt, wählen wir den Weg über das svn-repository (natürlich könnte man an dieser Stelle auch die tar.gz Archive von der Seite nehmen).

Wir legen also einen Ordner symfony unter /usr/share/php an und checken die einzelnen Versionen von Symfony aus. Für meine Projekte benötige ich 1.2, 1.3 und 1.4.

1
2
3
4
5

cd /usr/share/php
mkdir symfony
svn co http://svn.symfony-project.com/branches/1.2/ symfony12
svn co http://svn.symfony-project.com/branches/1.3/ symfony13
svn co http://svn.symfony-project.com/branches/1.4/ symfony14

Jetzt könnten wir mit

1

ln -s /usr/bin/symfony /usr/share/php/symfony/symfony14/data/bin/symfony

fest auf die neuste Version von Symfony linken. Allerdings ist das nicht die beste Variante, da man eventuell in einem Symfony-Projekt einer anderen Version arbeitet – was uns zu der Umständlichkeit von ./symfony führt. Für mich persönlich ist das nicht akzeptabel, weil ich das einfach immer falsch mache.

Bei dem Anlegen eines Symfony-Projekts wird ein kleines php-Script angelegt, das die in config/ProjectConfiguration.class.php hinterlegte Symfony-Version nutzt. Also wird ein kleines Script benötigt, das diese Gegebenheit ausnutzt. Folgendes Script kommt also in /usr/bin/symfony:

1
2

#!/usr/bin/env php
 

Befindet man sich in einem Symfony-Projekt-Ordner benutzt das Script das im Ordner hinterlegte symfony, andernfalls eine Fallback-Variante (in diesem Fall Symfony in Version 1.4).

Somit haben wir den vollen Komfort erlangt – falls es noch schöner geht, hinterlasst doch einen Kommentar

Falls man aber explizit eine Symfony-Version benötigt (zum Beispiel beim Anlegen eines neuen Projekts, die nicht der Standard-Version – also der Fallback-Version unseres Scripts – entspricht), sind folgende Symlinks noch nützlich:

1
2
3

ln -s /usr/bin/symfony12 /usr/share/php/symfony/symfony12/data/bin/symfony
ln -s /usr/bin/symfony13 /usr/share/php/symfony/symfony13/data/bin/symfony
ln -s /usr/bin/symfony14 /usr/share/php/symfony/symfony14/data/bin/symfony