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.

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.

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.

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

Die Vorteile – welche das nun genau sind, werde ich ein anderes Mal auflisten – von Kohana überwiegen in meinen Augen denen von Code Igniter. Nur eine Sache hat mich bisher ziemlich gestört: Die Kohana-Community bietet derzeit keinen Download der Dokumentation an. Doch das störte einen Code Igniter Umsteiger genauso wie mich und hat ein Script geschrieben, dass aus der Online-Version eine Offline-Version generiert – sehr praktisch für Pendler für mich, die im Zug gerne mal ein wenig lesen wollen oder aus anderen Gründen kein Internet zur Verfügung haben.

Also habe ich endlich eine Offline Dokumentation, die ich mir morgen abend nach der Arbeit reinziehen kann Was bedeutet das konkret für meinen Blog? Natürlich… Kohana-Beiträge! Außerdem hatte ich vor einen Vergleich zwischen Code Igniter und Kohana ziehen um die jeweiligen Vor- und Nachteile heraus zu stellen.

Da ich selbst lange genug danach gesucht habe, möchte ich euch das Archiv nicht vorenthalten:

• Kohana Offline Documentation