EiSEEX13.1.b - Test für alle Transitionen

[eNc]

Na ihr hübschen?

In der Aufgabe steht "Implementieren Sie einen Test für alle Transitionen." Und im Code ist "GumballMachineTest.TestX()" zu finden.
Ist das jetzt so gemeint, dass wir JEWEILS für jede Transition einen seperaten Test machen sollen, oder wir schreiben verschiedene Asserts in TestX() rein? Also ich habe verschiedene Asserts in TestX reingeschrieben, weil seperat für jede Transition würde wenig Sinn machen (meiner Meinung nach). Sollte ich allerdings mit meiner Meinung falsch liegen, so bitte ich euch mir dies mitzuteilen.

Ich danke euch rechtherzlich,

eNc

[CloneCommander]

Guter Punkt!

ich hätte es auch in eine gepackt, weil man dann schön nacheinander die Transitionen durch gehen kann. Wenn man eigene Methoden hat müsste man ja jedes mal erst zu dem Zustand gehen, bei dem man eine abgehende Transition testen will. Wäre ja alles doppelt und dreifach dann?!

CC

[sharky]

In
public void TestX(){...},
anstatt X schreibt man den Name der jeweilige Methode, z.B.
public void TestAddGumballs(){...}
usw.

Gruss,
sharky

[CloneCommander]

Hm, da steht ja wir sollen alle Transitionen testen - heißt das nicht wir sollen jeweils wirklich alle "Pfeile" die es gibt testen, und auch dann prüfen ob der zugehörige Zustand stimmt (was ich etwas schwierig finde, denn noch hab ich ja keine States!)

So wie du schreibst hieße es je jede Funktion einmal testen und fertig?! Quasi die Funktionen, die auf den Transitionen benötigt werden unabhängig vom Zustand?!

[sharky]

Ja, das meine ich.
Also noch einmal:
Du hast folgende Funktionen (fuer die Transitionen - das sind ja all moegliche Transitionen) in der Klasse GumballMachine:
public void addGumballs(int count);
public void insertQuarter();
public void removeQuarter();
public void turnHadle();

und jetzt schreibst du fuer jede Funktion je einen Test
public void testAddGumballs();
public void testInsertQuarter();
public void testRemoveQuarter();
public void testTurnHadle();


In diesen Test testest du genau das, was der Name der Funktion sagt, z.B. ob addGumballs(int count) richtig addiert usw.
Hier brauchst du, meiner Meinung nach, keine States ueberpruefen.

So habe ich alles verstanden.

Hoffe, das hilft.

Gruss,
sharky

[Maeher]

Blöderweise ist aber ob zB money erhöht wird vom Zustand abhängig.

Jeder Pfeil ist eine Transition. Das was du beschreibst ist nur die Eingabemenge.

edit: ist es möglicherweise zulässig, einen Konstruktor zu haben, der einen State übergeben bekommt? Dann könnte ich für jeden Zustand jede Eingabe recht einfach testen. Anders wird es wirklich irgendwie schwierig.

[Maeher]

ab das ganze jetzt wörtlich genommen und in _einem_ Test _alle_ Transitionen getestet.

[seth2k1]

Wäre es nicht Sinnvoller jedes State zu testen? Und so "schwer" ist es auch nicht, jeden State zu erreichen.

[Maeher]

Was willst du denn in einem State testen? Du kannst doch nur von jedem state alle von dort ausgehenden Transitionen testen.

Ich habe wie gesagt jetzt einfach einen einzigen Test geschrieben, der einen Lauf in dem Automaten testet, bei dem jede im Graph vorgesehene Transition mindestens einmal benutzt wird.

[eNc]

Schöner Hase.

[seth2k1]

naja, du hast doch ein bestimmtes verhalten im jeweilgen zustand, oder?

[Maeher]

Das Verhalten sind ja die Transitionen.

[seth2k1]

Und genau deswegen macht es durchaus Sinn für jeden State Tests zu schreiben, oder? Es macht das ganze einfach übersichtlicher und dient der Fehlererkennung. Auch wenn du mit deiner Methode "Alles in einem Test" zurecht kommst, eine gewisse Strukturierung erleichtert dritten die Arbeit. Auch wenn der dritte "nur" der Tutor ist

[Maeher]

Wenn ich ehrlich sein soll ist es mir ziemlich wurscht. Wir haben genug Punkte, von daher verzichte ich dann gerne auf die 3 Pünktchen oder wieviele es für den Test waren.

Es ist halt so, dass ich Text steht man solle einen Test für alle Transitionen schreiben. Dafür gibt es für mich zwei mögliche Interpretationen.

entweder ich schreibe |Zustandsmenge| * |Eingabemenge| Testcases, nämlich für jeden Pfeil genau einen, oder aber ich schreibe einen Testcase, in dem ich sämtliche Transitionen teste.

In den einzelnen Testcases könnte man leider auch nicht so leicht erkennen, was eigentlich falsch läuft. Wenn ich nämlich im Zustand GumballsQuarter Transitionen testen will, muss ich für jeden Testcase erstmal 2 Transitionen durchführen, bevor ich im richtigen Zustand in. Wenn bei denen dann schon was falsch ist, gibt es vermutlich einen fail, obwohl der Zustand möglicherweise korrekt implementiert ist und die Fehler ganz wo anders liegen.

Nunja... einem wird ja immer gesagt, dass man falls man denn mal in der Softwareentwicklung arbeitet, soll man bei allem was nicht 100% eindeutig ist doch nachfragen, wie etwas gemeint ist... Wenn Kunden bei solch eklatanten Mängeln der Anforderungsbeschreibung da genauso gerne antworten wie die Veranstalter, kommen sicher lustig Sachen raus am Ende.