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.
Vorab: Frohes neues Jahr!
Um den Start des Mips-Simulators Mars etwas komfortabler zu gestalten und inspiriert von dem yEd Graph Editor habe ich ein kleines Startup-Script für den genannten Simulator geschrieben.
Mit dem folgenden Schnippsel Code ist es nur noch notwendig, das Script (z.B. mars.sh) sowie die auf der Mars-Seite runterzuladene Mars.jar in einen gemeinsamen Ordner zu tun. Prinzipiell ist hier jeder Ordner möglich (vorzugsweise aber in einem Unterordner von /opt/ oder /usr/local/).
Mit einem Symlink von /usr/bin/mars zum Script lässt sich Mars dann ganz einfach im Terminal oder über ein Programm a la “Anwendung ausführen” von Gnome über mars ausführen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| #!/bin/sh
cd `dirname $0`
prg=`basename $0`
while [ -h $prg ] ; do
ls=`ls -ld $prg`
link=`expr "$ls" : '.*-> \(.*\)$'`
if expr "$link" : '.*/.*' > /dev/null; then
prg=$link
else
prg=`dirname $prg`/$link
fi
done
java -jar `dirname $prg`/Mars.jar |
Ich hoffe damit kann außer mir noch jemand etwas anfangen 
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:
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 |
Wie einige das schon mitbekommen habe, schreibe ich auch dieses Semester wieder ein Script. Wer also inzwischen meint schon viel zu lange gewartet zu haben, dem habe ich zwei Sachen zu sagen:
- Die Mitschriften sind bereits seit langem noch in MfI1 dabei gewesen.
- Bitte nehmt es mir nicht übel, wenn ihr auf die Builds länger warten müsst, ich mache nebenbei noch das SwtPra und das alleine ist an sich ein Fulltimejob…
Ach, da fällt mir noch eine Sache ein: Ich habe mitbekommen, dass noch jemand schreibt – wäre cool wenn sich derjenige mal bei mir melden könnte – vielleicht könnte man über eine Zusammenarbeit reden!
An dieser Stelle möchte ich mich noch bei einigen Personen bedanken, die mir geholfen haben. Vielen Dank an: Andre, Anke, Daniel und Kalle für das Bereitstellen von Mitschriften; Thomas für das Anfertigen der Mathezettel (Sorry SwtPra zieht 
)und Jan-Hendrik und Co (hierbei steht Jan-Hendrik an erster Stelle, weil er mir die meisten Mails geschrieben hat ) für die Zusendung von Fehlern und Korrekturen!
So, endlich ist es soweit: Das neue Mathe-Script ist online. Hat ne Weile gedauert, ich gebs zu, aber es ging nicht anders. Ich wünsche euch viel Spaß damit, aber weiterhin gilt: Bei Fehlern bei mir melden
Lange Zeit habe ich das LaTeX Plugin von Gedit benutzt um Übungszettel oder sonstiges zu texen. Langsam habe ich aber den Überblick über meine ganzen Tex-Sources verloren. Los ging also die Suche nach einer gescheiten IDE…
Read more…
Nein, der Blog ist nicht tot und ich auch nicht. Diesmal habe ich ein neues Projekt, dass ich vorstellen möchte.
Wie ich bereits geschrieben hatte, benutzen wir Dokuwiki zum erstellen von Mitschriften. Da wir von Anfang an für unsere Mathemitschriften LaTeX benutzt haben und ich eine absolute Sauklaue habe, habe ich mir überlegt eine PDF unserer Mitschriften zu erstellen. Und endlich ist sie soweit, dass sie veröffentlicht werden kann. Sources als auch eine fertige PDF sind in meinem Pool zu finden. auf der entsprechenden Projektseite zu finden.
Wer aber jetzt Angst vor meinem Pool hat, bekommt jetzt einmalig die Links zum ersten Release
Vor einiger Zeit habe ich das Seminar “Web 2.0 – Lernen in sozialen Netzwerken” an meiner Uni gefunden und fand diese Idee sehr spannend und werde sie weiter verfolgen.
Read more…
In den letzten Wochen habe ich ein Projekt mit dem PHP-Framework Code Igniter durchgezogen, was sehr viel Spaß gemacht hat. Dennoch denke ich, dass Code Igniter nicht perfekt ist, was ich leider an mehreren Stellen merken musste. Daher habe ich mich nach einem weiteren Framework umgeschaut und bin auf Kohana, einen Fork von Code Igniter gestoßen.
Read more…
Gestern war es wiedereinmal soweit: Der dritte Webmonday in der IT-Hochburg Paderborn. Da ich das erste mal darüber blogge, eine kurze Einführung in den Ablauf des Webmondays.
Read more…
