Fehler in der Musterlösung von Lab 01 Bowling

Benutzeravatar
dEeP-fRiEd
Kernelcompilierer
Kernelcompilierer
Beiträge: 432
Registriert: 19. Okt 2005 00:58
Wohnort: Darmstadt
Kontaktdaten:

Fehler in der Musterlösung von Lab 01 Bowling

Beitrag von dEeP-fRiEd »

Hi,

ich habe angefangen Ex. 2 Aufgabe 4.4 (Bowling Computer) zu implementieren und dabei auf der (beiliegenden) Musterlösung des Lab 1 aufgesetzt.

Kann es sein, dass diese einen Fehler enthält.
Und zwar nutze ich die itsCurrentFrame Variable um zu merken, wann ein Frame wechselt und der Spieler (der drann ist) gewechselt werden muss.

Leider wird das Frame aber teilweise zu früh gewechselt.

Ich denke, dass Problem liegt daran, dass die advanceFrame Methode in der Game Klasse noch this.firstThrowInFrame = true; setzen müsste! Da ja jedes mal wenn das Frame gewechselt wird, der nächste Wurf wieder der erste im Frame ist!

Bei meinem Test hats jeden Falls so funktioniert.
Aber ist das korrekt oder hab ich irgendwas übersehen/ falsch verstanden?

Meine Beispielsdaten:
-Spieler 1 wirft 5
-Spieler 1 wirft 5
-Wechsel
-Spieler 2 wirft 3
-Spieler 2 wirft 2
-Wechsel
-Spieler 1 wirft 10
-Wechsel
-Spieler 2 wirft 9
-ES ERFOLGT EIN FALSCHER WECHSEL DES FRAMES
(-die nachfolgende 1 von Spieler 2 wird für Spieler 1 gewertet...)
NOSCE TE IPSUM
visit: http://www.flicknetwork.net.tc

MuldeR
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 131
Registriert: 18. Okt 2005 16:14
Wohnort: (d)armstadt
Kontaktdaten:

Beitrag von MuldeR »

hmm, ich sehe zumindest nicht, wo firstThrowInFrame jemals wieder auf TRUE gesetzt werden sollte. Es wird einmalig(!) mit TRUE initialisiert und auf FALSE gesetzt, sobald nach einem Wurf nicht der Frame Zähler erhöht wird, d.h. im aktuellen Frame erfolgt ein zweiter Wurf. Das war's aber auch. Dein Vorschlag, firstThrowInFrame wieder auf TRUE zu setzen, sobald der Frame gewechselt wird, macht meiner Meinung nach Sinn! Würde diese "Korrektur" vorschlagen:

Code: Alles auswählen

private void advanceFrame()
{
  this.itsCurrentFrame = Math.min(10, this.itsCurrentFrame + 1);
  this.firstThrowInFrame = true;
}

Benutzeravatar
dEeP-fRiEd
Kernelcompilierer
Kernelcompilierer
Beiträge: 432
Registriert: 19. Okt 2005 00:58
Wohnort: Darmstadt
Kontaktdaten:

Beitrag von dEeP-fRiEd »

Danke für die Bestätigung.
Habe ich auch genau so abgeändert :)
NOSCE TE IPSUM
visit: http://www.flicknetwork.net.tc

Benutzeravatar
dinkelaker
Mausschubser
Mausschubser
Beiträge: 72
Registriert: 9. Okt 2007 10:35

Ist es wirklich ein Fehler im Sinne von agiler Entwicklung?

Beitrag von dinkelaker »

Hallo,

Ihr habt richtig erkannt Lösung, dass die Lösung für das Bowlingbeispiel aus dem R.C. Martin Buch an dieser Stelle sehr unschön ist.
Speziell die Notwendigkeit von firstThrowInFrame ist unklar und hat so einen "bad smell".

Ein paar Fragen, um die Diskussion anzuregen:
- Aber handelt es sich dabei wirklich ein Fehler im Sinne von agiler Entwicklung/TDD? Es laufen doch alle Test durch.
- Warum fällt der Test erst jetzt auf? Welche Anforderung aus dem Lab wird dadurch verletzt?
- Könnt ihr einen Testfall für den Single-Player Modus finden, so dass dieser fehlschlägt?

Gruß, Tom

jlerch
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 148
Registriert: 18. Okt 2005 14:45

Beitrag von jlerch »

Selbstverständlich laufen alle Tests durch, denn Scorer macht die Punkteberechnung unabhängig davon und Game bietet nur eine Schnittstelle wo das überhaupt Auswirkungen zeigen könnte (score).
Da passt es aber "zufällig", denn itsCurrentFrame ist wenn zu hoch durch das nicht zurücksetzen des Flags. Punkte zu weit nach vornehin berechnen macht aber nichts da Scorer das ausbügelt durch die 0-Standardwerte im score-array.
Ohne es getestet zu haben behaupte ich also mal das man keinen Test findet bei dem es fehlschlägt.

Um auf die Diskussionsaufforderung einzugehen würde ich behaupten, dass die Betrachtung in welchem Frame wir uns eigentlich befinden offenbar überflüssig ist und überhaupt nicht in Game gehört sondern in Scorer. Dieser rechnet es selbst sowieso nach.
Damit wird Game allerdings recht überflüssig als eigene Klasse.


Im übrigen fand ich die Musterlösung auch genau aus diesem Grund etwas schwer zu verstehen, da ich nach einer Aufgabenteilung gesucht habe.

Benutzeravatar
dinkelaker
Mausschubser
Mausschubser
Beiträge: 72
Registriert: 9. Okt 2007 10:35

Beitrag von dinkelaker »

Hallo Joe,

Du hast gute Argumente.
Zwar können wir den Fehler nicht mit den Tests identifiezieren,
aber es bleibt dennoch ein Fehler - oder?

Ich stimme mit Dir überein, dass wahrscheinlich kein Blackbox-Test das Problem findet.
Allerdings könnte wir einen Whitebox Test finden der fehlschlägt.
Z.B.:
1) addThrow(1) setzt firstThrowInFrame auf false, dannach ist lastBallInFrame() effektiv immer konstant 'true'.
2) addThrow(5) bewirkt einen Framewechsel
3) addThrow(3) bewirkt in Game Zeile 18 dass für lastBallInGame() true zurückgegeben und advanceFrame() aufgerufen wir, was sicherlich nicht korrekt ist.

Sprich die Acceptance Test die wir verwenden reichen hier nicht aus,
um den Fehler zu erkennen. Sicherlich ist die Funktion lastBallInGame()
nicht korrekt, aber das diese eine private Methode ist können wir sie in JUnit nicht so einfach Testen.

Was meint ihr, ist das Modul Game vollständig getestet? Stichwort: Testabdeckung.
Sind die Acceptance Tests falsch?
Wer ist dafür zuständig, dass eine möglichst vollständige Testabdeckung zustande kommt?

Gruß, Tom

Evgeni
Windoof-User
Windoof-User
Beiträge: 39
Registriert: 1. Dez 2004 19:22

Beitrag von Evgeni »

MuldeR hat geschrieben:
private void advanceFrame()
{
this.itsCurrentFrame = Math.min(10, this.itsCurrentFrame + 1);
this.firstThrowInFrame = true;
}
ich habe mich schon auch gewundert wieso die obige Zeile nirgends auftacht

Antworten

Zurück zu „Archiv“