Akzeptanztests und BDD mit PHP

Bergtroll · 21.01.2011, 16:52

Hallo liebe PHP Gemeinde,

wollte mal eine Fragerunde lostreten, wer von euch für PHP Akzeptanztests durchführt. Wie stellt Ihr sicher, dass eure Software das Richtige macht? Wie testet Ihr Weboberflächen? Wie organisiert ihr automatisierte Tests, so dass Sie wartbar bleiben?

Für meine Projekte benutze ich jetzt zum Datenbank testen sprachübergreifend Fitnesse mit der DbFit Erweiterung (http://fitnesse.org/, sowie http://www.fitnesse.info/dbfit). Das läuft auch mit Postgres, wenn man sich die pakete selbst holt, ihr könnt es in dieser Diskussion nachlesen.

Meine funktionalen PHP Model und Controller Tests kann ich ebenfalls aus Fitnesse dank phpslim starten.

Jetzt geht es an die große Aufgabe, wie ich jetzt und künftig meine Web-Gui Tests automatisiere. Ich benutze Selenium und Watir, die aber beide notwendigerweise auf sehr technischer Ebene angesiedelt sind. Als Businessregeln abbildende, selbsterklärende Tests eignen sie sich aber aus genau diesem Grund nicht. Außerdem ist diese Art techniknaher Tests im Zweifelsfalle fragil gegenüber Layout Änderungen (siehe http://cuke4ninja.com/chp_three_layers.html)..

Momentan benutze ich die Fitnesse Erweiterung GivWenZen (http://code.google.com/p/givwenzen/) und versuche das mit Selenium 2 und PageObjects zu verkuppeln. Aber atm ist das alles noch sehr hakelig.

Wie testet Ihr eure Webprojekte? Was versteht Ihr unter den Schlagworten "Specification by example", "ausführbare Spezifikation", Behavior Driven Development u.ä.? Nutzt Ihr das für PHP Projekte und wenn ja Wie?

Viele Grüße und ich freue mich auf eure Beiträge,

Bergtroll

mimomamu · 21.01.2011, 18:14

Das Logo ist witzig. Ist zwar im grünen Bereich, aber nahe bei 0. Habt ihr darüber nachgedacht, rot und grün zu vertauschen, so das die Nadel am Anschlag ist, wenn sie im grünen Bereich ist?

Bergtroll · 21.01.2011, 21:31

Hehe iss mir irgendwie garnicht aufgefallen. Aber woher weißt du, dass es nahe bei 0 ist? Vielleicht verläuft ja die Anzeige mathematisch korrekt gegen den Uhrzeigersinn? Aufjeden Fall kann man das Logo nach belieben austauschen, haben wir auch gemacht

Fitnesse ist allerdings nicht von mir, wie auch die anderen verlinkten Projekte.

Ich habe übrigens nochn ganz nettes Projekt gesehen, kennt und nutzt das jemand?

Viele Grüße,

Bergtroll

mquadrat · 25.01.2011, 09:54

Taugen GUI Tests überhaupt als Akzeptanztests?! Also da tue ich mich schwer damit. Natürlich kann der Kunder erst dann die User-Story freigeben wenn auch die GUI passt, aber da spielt auch Gestaltung, Ästhetik und Treue zum Corporate Design eine Rolle. Und das will ich eigentlich nicht in den Aktzeptanztests für die Funktionalität drin haben.

Ich wüsste jetzt auch gar nicht wie ich als Kunde so einen GUI Test definieren würde.

schnipseljagd · 25.01.2011, 16:30

Erstmal vielen Dank für das interessante Topic.

Bei uns in der Firma benutzen wir Selenium rc mit der PHPUnit-Selenium extension als Akzeptanz-Testsuite.

Allerdings sieht der Ablauf bei uns momentan so aus, das wir mit dem Kunden eine Story definieren (also die Spezifikationen erarbeiten) und die Akzeptanz-Tests im Nachhinein von den Entwicklern geschrieben werden.
Leider mit den typischen Problemen, "das habe ich so aber nicht gemeint".

Übrigens bietet PHPUnit auch "ein bischen" BDD unterstützung an:
http://www.phpunit.de/manual/current...velopment.html

Bergtroll · 27.01.2011, 13:16

Hey schön, dass sich zwei Diskutanten zum Thema gefunden haben

,

@mquadrat: Ich denke auch nicht, dass man bezüglich der von dir genannten Punkte eine Automatisierung erreichen kann, da diese vom subjektiven Empfinden abhängen. Aber unabhängig vom ästhetischen Wohlbefinden soll ja durch die GUI eine Reihe voneinander abgrenzbarer Features zugänglich gemacht werden. Ob die Features in ihrer technischen Funktionalität den Kundenerwartungen entsprechen, kann ich über automatisierte GUI-Tests prüfen. Läuft die Funktionalität übers GUI wie erwartet, darf ich folgern, dass sie auch in der zugrundeliegenden Controllerlogik funktioniert. Umgekehrt gilt das nicht. Deswegen denke ich, dass es notwendig ist, wenigstens das GUI zu testen. Im Optimalfall wird natürlich auch die Controllerlogik direkt an der GUI vorbei getestet. So kann ich, wenn in der GUI was schiefgeht, gleich entscheiden kann, ob es an der GUI selbst oder in der zugrundeliegenden Logikschicht liegt. Die zwingend manuelle Prüfung auf Ästhetik würde ich durch den Kunden vornehmen lassen, wenn ich sicher sein kann, dass mein Feature funktional läuft.

Imho würde ich dem Kunden auch nicht zumuten wollen, einen GUI Test im Detail zu definieren, sondern würde die Feature Beschreibung und die davon abgeleiteten Stories allgemein halten. Bsp:

Feature: Benutzerregistrierung
Ich | Als ein Besucher der Webseite
möchte | mich auf der Webseite registrieren
um | die auf registrierte Benutzer beschränkte Funktionalität zu nutzen

Feature: Benutzerregistrierung
Ich | Als ein Betreiber der Webseite
möchte | dass sich Leute auf meiner Webseite registrieren
um | höhere Nutzerzahlabhänge Werbeeinträge zu erzielen

Scenario: Erfolgreiche Registrierung
|Angenommen | Ein User ist als Gast online|
|und | der Benutzername $name existiert nicht|
|wenn | der User sich mit Name $name und Passwort $pass registriert|
|dann | ist er als $name registriert|
|und | auf der Seite eingeloggt|

Damit ist im Detail noch nichts gesagt, die Beschreibung ist allgemein genug, um eine ganze Reihe an Mglichkeiten zuzulassen. In Fitnesse würde man jetzt den zur Registrierung gehörigen Workflow in einer sog. Fixture Klasse definieren die folgende Methoden enthält:

einUserIstAlsGastOnline(): returns boolean
derBenutzernameExistiertNicht(): returns boolean
derUserRegistriertSichMitNameUndPasswort(name,pass ): returns void
derBenutzerIstAlsUserRegistriert(): returns boolean
derBenutzerIstAufDerSeiteEingeloggt(): returns boolean

Zuerst würden nun bei Aufruf des Tests die beiden Methoden:

einUserIstAlsGastOnline(): returns boolean
derBenutzernameExistiertNicht(): returns boolean

aufgerufen werden, um den gewünschten Ausgangszustand (username existiert nicht und user ist nicht eingeloggt) herzustellen. Der Eigentliche Workflow, also die Teilschritte, die in die Funktion "derUserRegistriertSich()" wandern, wird durch die Spezifikation bestimmt, wie der Prozess ablaufen soll. Beispielsweise:

Code:

derUserRegistriertSich(name,pass) {
  HomePage homePage = new HomePage();
  page.init();
  RegisterPage registerPage = homePage.clickRegister();
  registerPage.fillForm(name,pass);
  registerPage.register();
}

derBenutzerIstAufDerSeiteEingeloggt(username) {
  HomePage homePage = new HomePage();
  page.init();
  return homePage.isUserLoggedInWithName(username);
}

Die eigentlichen Selenium Code Aufrufe werden in PageObjects gekapselt. Wenn jetzt der Kunde beispielsweise Änderungswünsche bezüglich des Layouts hat, könnte man dieses ändern und müsste die Änderungen nur in den PageObjects unterbringen. Ich denke, damit ließe sich ein Test recht schnell auf ästhetisch bedingte Änderungswünsche anpassen?

Die Idee, das auf diese Art zu machen, stammt aus dem cuke4ninja Abschnitt "Web Automation". Meine ersten Umsetzungen auf diese Art geben mir das Gefühl, dass es ganz sinnvoll ist, den Test so aufzubauen ...

@schnipseljagd: Vielleicht könnte man neben der reinen Story auch die Schritte des Workflows mit dem Kunde festhalten? Dann könnte man sogar als mäßig talentierter Zeichner auch einfach die GUI Elemente aufmalen und mit Nummern oder Ähnliches die Workflow Schritte markieren?

Das PHPUnit BDD habe ich mal kurz überflogen. Mir gefällt es nicht so, weil ich meine User Stories ja gerne NICHT innerhalb von Programmcode ablege, sonder am Besten in einem Wiki o,ä.m, wo ich verlinken, Bilder einfügen, etc. kann...

mquadrat · 28.01.2011, 14:20

Wahrscheinlich bin ich zu code-zentrisch, aber mein View zeigt doch nur Werte des Models (bzw. ViewModels falls MVVM) an und registiert Befehle (in .NET Commands). Folglich: Teste ich das Funktionieren des Befehls und danach die Werte des Models erhalte ich die Aussage geht / geht nicht. Ob die Funktionen nun durch die GUI oder durch einen Testrunner ausgeführt werden ist doch zweitrangig. Alles was ich durch GUI Tests also gewinne ist die Aussage "der Knopf / Link triggert tatsächlich das richtige Command" und "das Label zeigt tatsächlich dieses Feld des Models". Lohnt dafür tatsächlich der Aufwand?

Die Definition der Testfälle müsste für einen GUI Akzeptanztest ja auch etwas umfangreicher sein, als das was du beschrieben hast. Beispielweise müsste der Test für das Anmelden ja enthalten "... Benutzer ist angemeldet und der Name wird in Label XY angezeigt". Lenkt das Hinzunehmen von Anzeige-Vorgaben nicht vom Kern ab?

Andererseits wird das Definieren der Testfälle für den Kunden natürlich intuitiver. Da hört man ja häufiger "Dann klicke ich da drauf und dann passiert das und das". Den Kunden allerdings wirklich dazu zu bekommen die Akzeptanztests selber auszuarbeiten halte ich immer noch für nicht machbar. Seltene Ausnahmen vielleicht im Enterprise-Bereich, bei dem es auch ein eigenes Projektteam beim Kunden gibt. Aber im Mittelstand kriegt man da kaum jemand dazu. Das wird als Teil der eingekauften Dienstleistung verstanden. Aber das ist natürlich ein anderer Punkt um den es ja hier nicht geht.

Sofern du den Prozess umsetzt würde mich aber mal eine "Success Story" interessieren. Also wie kam der Kunde damit klar, welche Probleme sind aufgetaucht..

schnipseljagd · 01.02.2011, 00:44

Zitat:

Zitat von mquadrat

Wahrscheinlich bin ich zu code-zentrisch, aber mein View zeigt doch nur Werte des Models (bzw. ViewModels falls MVVM) an und registiert Befehle (in .NET Commands). Folglich: Teste ich das Funktionieren des Befehls und danach die Werte des Models erhalte ich die Aussage geht / geht nicht. Ob die Funktionen nun durch die GUI oder durch einen Testrunner ausgeführt werden ist doch zweitrangig. Alles was ich durch GUI Tests also gewinne ist die Aussage "der Knopf / Link triggert tatsächlich das richtige Command" und "das Label zeigt tatsächlich dieses Feld des Models". Lohnt dafür tatsächlich der Aufwand?

Ja denn dadurch hast du ja gleichzeitig noch einen Integrations-Test (z.B. für Datenbank-Konfiguration oder auch für Javascript Geschichten), natürlich kannst du den Integrations-Test auch auf dem Controller ansetzen, aber hier würde ich doch eher Unit-Tests bevorzugen.

Zitat:

Zitat von mquadrat

Die Definition der Testfälle müsste für einen GUI Akzeptanztest ja auch etwas umfangreicher sein, als das was du beschrieben hast. Beispielweise müsste der Test für das Anmelden ja enthalten "... Benutzer ist angemeldet und der Name wird in Label XY angezeigt". Lenkt das Hinzunehmen von Anzeige-Vorgaben nicht vom Kern ab?

Hier ist natürlich die Frage wie umfangreich GUI-Tests wirklich sein müssen, aber das muss man denke ich im Einzelfall entscheiden.

Zitat:

Zitat von mquadrat

Andererseits wird das Definieren der Testfälle für den Kunden natürlich intuitiver. Da hört man ja häufiger "Dann klicke ich da drauf und dann passiert das und das". Den Kunden allerdings wirklich dazu zu bekommen die Akzeptanztests selber auszuarbeiten halte ich immer noch für nicht machbar. Seltene Ausnahmen vielleicht im Enterprise-Bereich, bei dem es auch ein eigenes Projektteam beim Kunden gibt. Aber im Mittelstand kriegt man da kaum jemand dazu. Das wird als Teil der eingekauften Dienstleistung verstanden. Aber das ist natürlich ein anderer Punkt um den es ja hier nicht geht.

Bei uns löst gerade das Weglassen dieser Schritte mit dem Kunden häufig doppelte Arbeit aus. Deswegen stellt sich hier die Frage, ob es nicht unprofessionell von uns Entwicklern ist, keine genaue Definition der Akzeptanztests mit dem Kunden zu fordern (natürlich wird man im Großteil der Fälle die Akzeptanztests mit dem Kunden zusammen erarbeiten müssen),
Dabei sollte man natürliche immer die Relation im Auge behalten, wie z.B. den Umfang des Projekts.
Wie die Akzeptanz-Tests dann im Detail aussehen muss man sich halt auch für das jeweilige Projekt überlegen. Auch wenn ich denke, dass Automatisierung ab einem gewissen Umfang aufjedenfall Sinn ergibt.

@Bergtroll Ich denke auch, dass es in Zukunft bei uns mehr in die Richtung gehen sollte.

Einen schönen Einblick in dem Umgang mit der Ausarbeitung von User-Stories sowie mit der Definition von Akzeptanztests mit dem Kunden bietet übrigens dieses Buch, auch wenn die beiden Authoren vollständig auf Gui-Test-Automatisierung verzichtet haben (was sie am Ende allerdings selbst bereuen):
http://www.amazon.de/Extreme-Program...6517124&sr=8-1

mquadrat · 01.02.2011, 18:07

Gut, sobald im Javascript mehr gemacht wird als Animationen oder ähnliches, dann muss man auch das JS testen.

Ich denke es kommt drauf an was genau der Kunde eigentlich einkauft. Wenn wirklich nur eine Software-Lösung für ein gegebenes Problem gefordert wird, dann muss der Kunde zwingend bei den Akzeptanztests eingebunden werden. Hat der Kunde allerdings nur eine mehr oder weniger difuse Problemstellung, dann ist das Erarbeiten der Vorgehensweise und damit die Akzeptanztests auch Teil des Auftrags. Schwierig sind halt die Zwischendinger.
Es kommt auch auf den Kundentyp an. Ich habe die Erfahrung gemacht, dass die Kunden die hinterher mit "das war doch selbstvertändlich, dass das so ist, das muss man doch nicht extra erwähnen" kommen die gleichen sind, die aus Prinzip keine Akzeptanztests machen, weil das ja zur Dienstleistung des Entwicklers gehört. Da muss man dann einfach die Entscheidung treffen ob man das Risiko für diese Kunden zu arbeiten eingeht.

Ich würde somit für die Vorgehensweise stimmen, bei der die Akzeptanztests nicht zwingend vom Kunden definiert werden müssen, aber zwingend vom Kunden abgenommen werden müssen.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

21.01.2011, 16:52
Bergtroll Benutzer Registriert seit: 15.04.2009 Beiträge: 30	Akzeptanztests und BDD mit PHP Hallo liebe PHP Gemeinde, wollte mal eine Fragerunde lostreten, wer von euch für PHP Akzeptanztests durchführt. Wie stellt Ihr sicher, dass eure Software das Richtige macht? Wie testet Ihr Weboberflächen? Wie organisiert ihr automatisierte Tests, so dass Sie wartbar bleiben? Für meine Projekte benutze ich jetzt zum Datenbank testen sprachübergreifend Fitnesse mit der DbFit Erweiterung (http://fitnesse.org/, sowie http://www.fitnesse.info/dbfit). Das läuft auch mit Postgres, wenn man sich die pakete selbst holt, ihr könnt es in dieser Diskussion nachlesen. Meine funktionalen PHP Model und Controller Tests kann ich ebenfalls aus Fitnesse dank phpslim starten. Jetzt geht es an die große Aufgabe, wie ich jetzt und künftig meine Web-Gui Tests automatisiere. Ich benutze Selenium und Watir, die aber beide notwendigerweise auf sehr technischer Ebene angesiedelt sind. Als Businessregeln abbildende, selbsterklärende Tests eignen sie sich aber aus genau diesem Grund nicht. Außerdem ist diese Art techniknaher Tests im Zweifelsfalle fragil gegenüber Layout Änderungen (siehe http://cuke4ninja.com/chp_three_layers.html).. Momentan benutze ich die Fitnesse Erweiterung GivWenZen (http://code.google.com/p/givwenzen/) und versuche das mit Selenium 2 und PageObjects zu verkuppeln. Aber atm ist das alles noch sehr hakelig. Wie testet Ihr eure Webprojekte? Was versteht Ihr unter den Schlagworten "Specification by example", "ausführbare Spezifikation", Behavior Driven Development u.ä.? Nutzt Ihr das für PHP Projekte und wenn ja Wie? Viele Grüße und ich freue mich auf eure Beiträge, Bergtroll


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

21.01.2011, 18:14
mimomamu Erfahrener Benutzer Registriert seit: 23.08.2010 Beiträge: 495 PHP-Kenntnisse: Fortgeschritten	Das Logo ist witzig. Ist zwar im grünen Bereich, aber nahe bei 0. Habt ihr darüber nachgedacht, rot und grün zu vertauschen, so das die Nadel am Anschlag ist, wenn sie im grünen Bereich ist? __________________ Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

21.01.2011, 21:31
Bergtroll Benutzer Registriert seit: 15.04.2009 Beiträge: 30	Hehe iss mir irgendwie garnicht aufgefallen. Aber woher weißt du, dass es nahe bei 0 ist? Vielleicht verläuft ja die Anzeige mathematisch korrekt gegen den Uhrzeigersinn? Aufjeden Fall kann man das Logo nach belieben austauschen, haben wir auch gemacht Fitnesse ist allerdings nicht von mir, wie auch die anderen verlinkten Projekte. Ich habe übrigens nochn ganz nettes Projekt gesehen, kennt und nutzt das jemand? Viele Grüße, Bergtroll

25.01.2011, 09:54
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.020 PHP-Kenntnisse: Fortgeschritten	Taugen GUI Tests überhaupt als Akzeptanztests?! Also da tue ich mich schwer damit. Natürlich kann der Kunder erst dann die User-Story freigeben wenn auch die GUI passt, aber da spielt auch Gestaltung, Ästhetik und Treue zum Corporate Design eine Rolle. Und das will ich eigentlich nicht in den Aktzeptanztests für die Funktionalität drin haben. Ich wüsste jetzt auch gar nicht wie ich als Kunde so einen GUI Test definieren würde. __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

25.01.2011, 16:30
schnipseljagd Neuer Benutzer Registriert seit: 29.05.2010 Beiträge: 8 PHP-Kenntnisse: Fortgeschritten	Erstmal vielen Dank für das interessante Topic. Bei uns in der Firma benutzen wir Selenium rc mit der PHPUnit-Selenium extension als Akzeptanz-Testsuite. Allerdings sieht der Ablauf bei uns momentan so aus, das wir mit dem Kunden eine Story definieren (also die Spezifikationen erarbeiten) und die Akzeptanz-Tests im Nachhinein von den Entwicklern geschrieben werden. Leider mit den typischen Problemen, "das habe ich so aber nicht gemeint". Übrigens bietet PHPUnit auch "ein bischen" BDD unterstützung an: http://www.phpunit.de/manual/current...velopment.html

27.01.2011, 13:16
Bergtroll Benutzer Registriert seit: 15.04.2009 Beiträge: 30	Hey schön, dass sich zwei Diskutanten zum Thema gefunden haben , @mquadrat: Ich denke auch nicht, dass man bezüglich der von dir genannten Punkte eine Automatisierung erreichen kann, da diese vom subjektiven Empfinden abhängen. Aber unabhängig vom ästhetischen Wohlbefinden soll ja durch die GUI eine Reihe voneinander abgrenzbarer Features zugänglich gemacht werden. Ob die Features in ihrer technischen Funktionalität den Kundenerwartungen entsprechen, kann ich über automatisierte GUI-Tests prüfen. Läuft die Funktionalität übers GUI wie erwartet, darf ich folgern, dass sie auch in der zugrundeliegenden Controllerlogik funktioniert. Umgekehrt gilt das nicht. Deswegen denke ich, dass es notwendig ist, wenigstens das GUI zu testen. Im Optimalfall wird natürlich auch die Controllerlogik direkt an der GUI vorbei getestet. So kann ich, wenn in der GUI was schiefgeht, gleich entscheiden kann, ob es an der GUI selbst oder in der zugrundeliegenden Logikschicht liegt. Die zwingend manuelle Prüfung auf Ästhetik würde ich durch den Kunden vornehmen lassen, wenn ich sicher sein kann, dass mein Feature funktional läuft. Imho würde ich dem Kunden auch nicht zumuten wollen, einen GUI Test im Detail zu definieren, sondern würde die Feature Beschreibung und die davon abgeleiteten Stories allgemein halten. Bsp: Feature: Benutzerregistrierung Ich \| Als ein Besucher der Webseite möchte \| mich auf der Webseite registrieren um \| die auf registrierte Benutzer beschränkte Funktionalität zu nutzen Feature: Benutzerregistrierung Ich \| Als ein Betreiber der Webseite möchte \| dass sich Leute auf meiner Webseite registrieren um \| höhere Nutzerzahlabhänge Werbeeinträge zu erzielen Scenario: Erfolgreiche Registrierung \|Angenommen \| Ein User ist als Gast online\| \|und \| der Benutzername $name existiert nicht\| \|wenn \| der User sich mit Name $name und Passwort $pass registriert\| \|dann \| ist er als $name registriert\| \|und \| auf der Seite eingeloggt\| Damit ist im Detail noch nichts gesagt, die Beschreibung ist allgemein genug, um eine ganze Reihe an Mglichkeiten zuzulassen. In Fitnesse würde man jetzt den zur Registrierung gehörigen Workflow in einer sog. Fixture Klasse definieren die folgende Methoden enthält: einUserIstAlsGastOnline(): returns boolean derBenutzernameExistiertNicht(): returns boolean derUserRegistriertSichMitNameUndPasswort(name,pass ): returns void derBenutzerIstAlsUserRegistriert(): returns boolean derBenutzerIstAufDerSeiteEingeloggt(): returns boolean Zuerst würden nun bei Aufruf des Tests die beiden Methoden: einUserIstAlsGastOnline(): returns boolean derBenutzernameExistiertNicht(): returns boolean aufgerufen werden, um den gewünschten Ausgangszustand (username existiert nicht und user ist nicht eingeloggt) herzustellen. Der Eigentliche Workflow, also die Teilschritte, die in die Funktion "derUserRegistriertSich()" wandern, wird durch die Spezifikation bestimmt, wie der Prozess ablaufen soll. Beispielsweise: Code: derUserRegistriertSich(name,pass) { HomePage homePage = new HomePage(); page.init(); RegisterPage registerPage = homePage.clickRegister(); registerPage.fillForm(name,pass); registerPage.register(); } derBenutzerIstAufDerSeiteEingeloggt(username) { HomePage homePage = new HomePage(); page.init(); return homePage.isUserLoggedInWithName(username); } Die eigentlichen Selenium Code Aufrufe werden in PageObjects gekapselt. Wenn jetzt der Kunde beispielsweise Änderungswünsche bezüglich des Layouts hat, könnte man dieses ändern und müsste die Änderungen nur in den PageObjects unterbringen. Ich denke, damit ließe sich ein Test recht schnell auf ästhetisch bedingte Änderungswünsche anpassen? Die Idee, das auf diese Art zu machen, stammt aus dem cuke4ninja Abschnitt "Web Automation". Meine ersten Umsetzungen auf diese Art geben mir das Gefühl, dass es ganz sinnvoll ist, den Test so aufzubauen ... @schnipseljagd: Vielleicht könnte man neben der reinen Story auch die Schritte des Workflows mit dem Kunde festhalten? Dann könnte man sogar als mäßig talentierter Zeichner auch einfach die GUI Elemente aufmalen und mit Nummern oder Ähnliches die Workflow Schritte markieren? Das PHPUnit BDD habe ich mal kurz überflogen. Mir gefällt es nicht so, weil ich meine User Stories ja gerne NICHT innerhalb von Programmcode ablege, sonder am Besten in einem Wiki o,ä.m, wo ich verlinken, Bilder einfügen, etc. kann...

28.01.2011, 14:20
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.020 PHP-Kenntnisse: Fortgeschritten	Wahrscheinlich bin ich zu code-zentrisch, aber mein View zeigt doch nur Werte des Models (bzw. ViewModels falls MVVM) an und registiert Befehle (in .NET Commands). Folglich: Teste ich das Funktionieren des Befehls und danach die Werte des Models erhalte ich die Aussage geht / geht nicht. Ob die Funktionen nun durch die GUI oder durch einen Testrunner ausgeführt werden ist doch zweitrangig. Alles was ich durch GUI Tests also gewinne ist die Aussage "der Knopf / Link triggert tatsächlich das richtige Command" und "das Label zeigt tatsächlich dieses Feld des Models". Lohnt dafür tatsächlich der Aufwand? Die Definition der Testfälle müsste für einen GUI Akzeptanztest ja auch etwas umfangreicher sein, als das was du beschrieben hast. Beispielweise müsste der Test für das Anmelden ja enthalten "... Benutzer ist angemeldet und der Name wird in Label XY angezeigt". Lenkt das Hinzunehmen von Anzeige-Vorgaben nicht vom Kern ab? Andererseits wird das Definieren der Testfälle für den Kunden natürlich intuitiver. Da hört man ja häufiger "Dann klicke ich da drauf und dann passiert das und das". Den Kunden allerdings wirklich dazu zu bekommen die Akzeptanztests selber auszuarbeiten halte ich immer noch für nicht machbar. Seltene Ausnahmen vielleicht im Enterprise-Bereich, bei dem es auch ein eigenes Projektteam beim Kunden gibt. Aber im Mittelstand kriegt man da kaum jemand dazu. Das wird als Teil der eingekauften Dienstleistung verstanden. Aber das ist natürlich ein anderer Punkt um den es ja hier nicht geht. Sofern du den Prozess umsetzt würde mich aber mal eine "Success Story" interessieren. Also wie kam der Kunde damit klar, welche Probleme sind aufgetaucht.. __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

01.02.2011, 18:07
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.020 PHP-Kenntnisse: Fortgeschritten	Gut, sobald im Javascript mehr gemacht wird als Animationen oder ähnliches, dann muss man auch das JS testen. Ich denke es kommt drauf an was genau der Kunde eigentlich einkauft. Wenn wirklich nur eine Software-Lösung für ein gegebenes Problem gefordert wird, dann muss der Kunde zwingend bei den Akzeptanztests eingebunden werden. Hat der Kunde allerdings nur eine mehr oder weniger difuse Problemstellung, dann ist das Erarbeiten der Vorgehensweise und damit die Akzeptanztests auch Teil des Auftrags. Schwierig sind halt die Zwischendinger. Es kommt auch auf den Kundentyp an. Ich habe die Erfahrung gemacht, dass die Kunden die hinterher mit "das war doch selbstvertändlich, dass das so ist, das muss man doch nicht extra erwähnen" kommen die gleichen sind, die aus Prinzip keine Akzeptanztests machen, weil das ja zur Dienstleistung des Entwicklers gehört. Da muss man dann einfach die Entscheidung treffen ob man das Risiko für diese Kunden zu arbeiten eingeht. Ich würde somit für die Vorgehensweise stimmen, bei der die Akzeptanztests nicht zwingend vom Kunden definiert werden müssen, aber zwingend vom Kunden abgenommen werden müssen. __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de