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.

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