Clanintern Clanintern Clanintern

Forum

Öffentliche Foren
FORUM: Spiele & Computer THEMA: [PHP] Unit tests
AUTOR BEITRAG
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#1 - 15.04 18:28

Hoi Ihr.

Wer von euch testet seinen Code, programmiert im besten Fall sogar testgetrieben?
Womit? PHPUnit?
Worin? Gibt es außer der kostenpflichtigen (und mit Verlaub recht teuren) Zend-Lösung eine halbwegs schöne kostenfreie?
Schreibt mal was dazu
horst

RANG Prophet of Clanintern

#2 - 16.04 15:51

JUnit
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#3 - 16.04 15:59

Ist halt unter PHP nicht ganz so der Bringer.
vaest´ark // patrick *circle of confusion*

RANG Master of Clanintern

#4 - 16.04 16:05

also mein programmier-flow lässt sich überhaupt nicht mit den anforderungen vereinbaren die ein testgetriebener workflow stellt.

meine apis/klassen sehen des öfteren mal so aus:


class foo{

public function __construct(){
// nix.
}

public function irgendwas($a = NULL, $b = NULL, $c = NULL){
// TODO: Implementieren!
return $benoetigterwert;
}

public function irgendwas2(){
throw new exception('nicht implementiert');
}

}

und dann wird diese klasse munter drauf-los-verwendet und bei bedarf angepasst...


ne, also testgetrieben programmieren fang ich mir erst an, wenn ich irgendwann mal DFDe und UML-Modelle für die projekte mache(n muss).
horst

RANG Prophet of Clanintern

#5 - 16.04 20:43

Auch wahr. Im Topic hab ich das PHP überlesen.
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#6 - 16.04 21:02

Naja, grundsätzlich finde ich die Idee eigentlich enorm cool. Erstens soll ich, zweitens will ich das in meinem aktuellen Projekt verwenden. Nachdem das Projekt einen Zeitansatz von vier Wochen hat (harte Deadline), werde ich hierfür wohl mal das Zend-Studio antesten.



Der Projektverlauf sieht hierfür einfach wie folgt aus, wobei mir bzw. er Firma in der ich momentan beschäftigt bin die Rolle des Dienstleisters zukommt:

1. Kunde gibt Anforderungen im Fließtext mit einigen Bildern, viel auch nur verbal

2. Dienstleister analysiert und stellt ein Stichpunktkonzept auf. In diesem Fall ein zehnseitiges Dokument mit acht Hauptpunkten, von denen sechs Programmieraufgaben bzw. geforderte Funktionen des Programmierergebnisses beschreiben

3. Kunde "unterschreibt" das Konzept, Vertragsschluss

4. Ausarbeitung eines grundlegenden Datenbankmodells, wobei "logische Objekte" Einfluss auf die Struktur haben nach "was hab ich, was will ich haben"

5. Ausarbeitung eines Klassenkonzeptes durch Definition von über Interfacees durch deren pubic Methoden. Auf Performanceaspekte wird primär bei der Wahl der Parameterübergaben Rücksicht genommen.

6. Ggf. erforderliche Änderungen der Datenbankstruktur

7. Definition und Implementierung von Testfällen, um den in 2 erarbeiteten Vertrag in allen Punkten prüfen zu können.

8. Implementierung einer Mantelklasse, die die bisherige Klasstenstruktur ausführt und erhaltene Datenstrukturen Output der Zielsprache -- mehrheitlich HTML -- erzeugt.

9. Implementierung aller Interfaces in Klassen mit Ziel "alle Tests positiv". Output an allen Stellen Datencontainer.



Grundlegender Vorteil:

- 1 und 2 geschehen recht informell im Fließtext, lediglich "umfassendes grundlegendes Informatik-Knowhow" ist erforderlich.

- 4, 5 und 6 entsprechen einer Nahtstellendefinition und werden sinnvollerweise "gemeinsam" von allen beteiligten Entwicklern durchgeführt. Aufwand 50% Brainstorming, 50% "mit der Realität in Einklang bringen".

- 7 kann bequem unter allen Entwicklern aufgeteilt werden, einfach den in 2 ausgearbeiteten Vertrag in gleichgroße Teile zerlegen, Tests schreiben. Anschließend möglichst bei mehreren Entwicklern Tests von jeweils einem anderen Entwickler Reviewen lassen, selbst Tests anderer reviewen.

- 8 kann ohne funktionierenden Arbeitscode vollständig erarbeitet und implementiert werden, da die Rückgabe aller Nahtstellen definiert ist. Somit kann ein Entwickler diesen Arbeitsschritt alleine erledigen, während andere mit 9 beginnen.

- 9 kann ebenso bequem unter allen Entwicklern aufgeteilt werden. Einfach die in 5 erarbeiteten Interfaces gleichmäßig unter allen Entwicklern aufteilen. Ein "was hast du damit gmeint" oder (schlimmer) ein "Ich dachte das wär so. Is jetzt blöd dass du das anders gemeint hast", die sich bei Gruppenprojekten dann gerne mal ergeben, wenn die Grundlage oder einzelne Zulieferer des eigenen Teilstücks noch nicht zur Verfügung stehen (die werden ja gerade parallel von anderen entwickelt) wird es nicht geben. Solange Tests auf meinem Code Fehler werfen muss ich noch ran, sobald alle Tests auf meinem Code sind alle meine Annahmen und Interpretationen rechtmäßig.

- Nachträglich gewünschte Features (ob Teil der Auftragsleistung oder als Folgeauftrag spielt keine Rolle) lassen sich bequem einfügen, die Funktionstüchtigkeit des restlichen Codes lässt sich leicht prüfen. Nachträglich aufgrund von Funktionszuwachs durchgeführte Änderungen dürfen keinen der anfangs definierten Tests scheitern lassen, da damit der Grundauftrag nicht erfüllt wäre. Ein "oh, DB-Struktur geändert, jetzt ist zwar das Feature drin, dafür fliegt das Ding auf der anderen Seite auseinander" kann so verhindert werden.

- Debugging während der Entwickelung ist deutlich einfacher, weil nicht bei jedem Fehlverhalten mit unzähligen Breakpoints ermittelt werden muss, an welcher Stelle Variablen das erste mal anders sind als erwartet.



So jedenfalls die Theorie
horst

RANG Prophet of Clanintern

#7 - 17.04 16:32

quote:
Ein "oh, DB-Struktur geändert, jetzt ist zwar das Feature drin, dafür fliegt das Ding auf der anderen Seite auseinander" kann so verhindert werden.


Das ist ja auch der Sinn von den Unit-Tests ;-)

Aus aktuellem Anlass achte auch darauf, dass deine Tests nicht nur den "Happy Path" abdecken, also so wie du es dir denkst, dass es funktionieren sollte. Zusätzlich solltest du def. abprüfen was illegale Argumente so mit deiner Real-Implementierung machen. Am Beispiel String: null oder "" oder " " oder " abc" oder "abc ".

Darüber hinaus würde ich auch auf die Code-Coverage achten. Dann siehst du, ob in deiner Real-Implementierung mit den Testfällen alles abgedeckt ist oder ob irgendwie durch 2 zu lange Nächte "Leichen" in den Code gekommen sind.
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#8 - 17.04 19:02

Jo, da wird n Testset geschrieben, das sowohl positive als auch negative Tests beinhaltet. Negative nicht als "der Test schlägt fehl" sondern "der Test prüft, ob fehlerhafte Eingaben auch richtig als fehlerhaft erkannt werden". In meinem aktuellen Projekt hab ich mal 20% der Zeit für das Erstellen von Testsets eingeplant, während auf einen anschließenden Betatest nur 10% entfallen. Damit nehmen die beiden Testsituationen Unit-Test und Betatest mehr Zeit ein als die Einzelpunkte "aufstellen der DB-Struktur", "Definition von Interfaces" und "implementieren der Interfaces".