ex05, Aufgabe 4

Toobee
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 7. Apr 2011 12:58

ex05, Aufgabe 4

Beitrag von Toobee »

Ich habe ne frage zu Aufgabe 4,

die Tests dürfen nicht verändert werden?

der Test hier:

@Test
public void testWitdrawFromOpenAccount() throws Exception {
final Account a = createAndOpenAccount(10, 1000);
a.withdraw(10);
a.withdraw(10);
}

Was genau wird den erwartet, dass ein JuniorAccount hier machen soll? Der DbC schlägt fehl da ein Junior keinen Kredit hat und daher bei der zweiten Abhebung das Limit sprengt. Wenn ich jetzt eine Contract violation erwarte klappt er für die anderen 2 Varianten nicht, weil die ja krdit haben.

Ist das Ziel bei der Aufgabe ein LSP konformes Design zu machen oder das DbC funktioniert und die Klassen das tun was sie sollen?

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Re: ex05, Aufgabe 4

Beitrag von marcel_b »

die tests dürfen verändert werden - und müssen u.U. sogar verändert werden( je nachdem wie ihr euer neues LSP und DbC konformes Design bauen möchtet.)

Toobee
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 7. Apr 2011 12:58

Re: ex05, Aufgabe 4

Beitrag von Toobee »

Wir haben ein Veständnisproblem; Muss die Struktur geändert werden? Oder reicht es, wenn die Tests mit kkleinen Modifikationen durchlaufen und die Klassen keine throws() mehr machen?

Dann noch was, der SavingAccountTest scheint nicht benutzt zu werden?

marcel_b
Nerd
Nerd
Beiträge: 600
Registriert: 31. Okt 2006 17:04
Kontaktdaten:

Re: ex05, Aufgabe 4

Beitrag von marcel_b »

Zu Muss das Design geändert werden:
"Keine Ahnung". Wenn ihr die der ersten Teilaufgabe DbC Verletzungen festgestellt habt, würde es mich jedoch wundern, wenn ihr ohne eine Design Änderung auskommen würdet - vorausgesetzt ihr erfüllt noch immer alle Constraints der Account (Sub)Klassen.

Ja, SavingAccountsTest muss euch nicht interessieren.

Parasiris
Windoof-User
Windoof-User
Beiträge: 30
Registriert: 1. Okt 2007 16:04

Re: ex05, Aufgabe 4

Beitrag von Parasiris »

Hi,

wir haben gerade auch ein ähnliche Problem. WIr haben nun ein neues Design erstellt, doch damit haben wir auch ein kleines Problem mit den unterschiedlichen Verhaltensweisen der Accounts. z.B. ist in usnerer neuen Klasse eine methode withdraw vorhanden die mit der vorbedingung verknüpft ist, dass ein bestimmter maximal erlaubte Wert abgebucht werden kann.
Nun kann ja der Client der ein Account Objekt bekommt nicht wissen, dass man z.B. beim JuniorAccount von 100€ keine 60€ abbuchen kann. Somit kommt bei diesem Test dann eine Precondition-Verletzung die bei dem CheckingAccount nicht autritt.
Ist das bei uns ein fehlerhaftes Design oder wie sollen wir mit solchen Tests umgehen? Ein ähnliches Problem tritt beim Schließen von Accounts auf, die bei dem SavingAccount eine mindestPeriode abfragen und bei den anderen nicht. :(

Wäre die Idee vllt passend: Definieren einer Precodnition von max 50€ abbuchen und Auflockerung wenn mehr erlaubt ist?

Toobee
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 7. Apr 2011 12:58

Re: ex05, Aufgabe 4

Beitrag von Toobee »

>wie sollen wir mit solchen Tests umgehen?

Du musst die Tests ändern. Es ist ja z.B. richtig, dass ein Account ohne Limit hochgeht, wenn du mehr abziehst als drauf ist und dann die Invariante verletzt wird, die im Interface festgelegt ist. Teil einfach die Testfälle aus und kodier die Testtypen hart rein, auch wenn der vorgegebene Testcode das nicht unbedingt auf eine schöneweise zu lässt - es ist logisch korrekt, dass ein Junior nicht mehr abziehen kann als da ist.

Das was an Tests vorgegeben ist, wirkt dem Verständnis und der Lösung der Aufgabe doch sehr negativ entgegen :mrgreen:

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Re: ex05, Aufgabe 4

Beitrag von MisterD123 »

Parasiris hat geschrieben:Hi,

wir haben gerade auch ein ähnliche Problem. WIr haben nun ein neues Design erstellt, doch damit haben wir auch ein kleines Problem mit den unterschiedlichen Verhaltensweisen der Accounts. z.B. ist in usnerer neuen Klasse eine methode withdraw vorhanden die mit der vorbedingung verknüpft ist, dass ein bestimmter maximal erlaubte Wert abgebucht werden kann.
Nun kann ja der Client der ein Account Objekt bekommt nicht wissen, dass man z.B. beim JuniorAccount von 100€ keine 60€ abbuchen kann. Somit kommt bei diesem Test dann eine Precondition-Verletzung die bei dem CheckingAccount nicht autritt.
Ist das bei uns ein fehlerhaftes Design oder wie sollen wir mit solchen Tests umgehen? Ein ähnliches Problem tritt beim Schließen von Accounts auf, die bei dem SavingAccount eine mindestPeriode abfragen und bei den anderen nicht. :(

Wäre die Idee vllt passend: Definieren einer Precodnition von max 50€ abbuchen und Auflockerung wenn mehr erlaubt ist?
du kannst methoden in requirements verwenden glaub ich. Probier mal eine boolean isAllowedToWithdraw(){,,} und dann mit @REQUIRE(isAllowedToWithdraw()) oder sowas, dadurch kannst du die precondition in subklassen anpassen sozusagen. Angaben ohne gewähr, aber ich *glaube* das geht.

Parasiris
Windoof-User
Windoof-User
Beiträge: 30
Registriert: 1. Okt 2007 16:04

Re: ex05, Aufgabe 4

Beitrag von Parasiris »

Also Methoden für die Requirements gehen, habe ich auch verwendet, z.B. für die Erlaubnis ob man ein Konto schließen kann.
Jedoch hilft mir das bei dem oben genannten Problem denke ich nicht weiter, da eben die Methoden manchmal eine Precondition verletzen und manchmal nicht. Das war ja eben mein Problem. Die Sache war, dass man eben nicht immer sagen kann ich erwarte nun eine Verletzung der Precondition, da die Accounts unterschiedliche Spezifikationen für das Schließen des Kontos haben. Und z.B. das Konto zu schließen finde ich ist mit einer neuen Klasse Account ein "legitimer" Test den man auf einem Account-Objekt ausführen kann. Schlägt aber dann manchmal fehl und manchmal nicht.

@Toobee
Was meinst du mit verteilen und hart codieren in dem Fall?

Toobee
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 7. Apr 2011 12:58

Re: ex05, Aufgabe 4

Beitrag von Toobee »

>Was meinst du mit verteilen und hart codieren in dem Fall?
Manche tests gehen nicht, da du typ abhängig reagieren musst
@Test
public void testCloseBalancedAccount() throws Exception {
final Account a = createAndOpenAccount(10, 1000);
a.close();
}

Für einen saving account müsste man hier einen pre-condition violation erwarten, für die anderen nicht. Das musst du aufteilen

@Test
public void testCloseBalancedAccount() throws Exception {
final Account a1 = createCheckingAccount(10, 1000);
a1.close();
final Account a2 = createJuniorCheckingAccount(10, 1000);
a2.close();
}
@Test(expect = Precondition.class) //violates min. period
public void testCloseBalancedAccount() throws Exception {
final Account a1 = createSavingAccount(10, 1000);
a1.close();
}

diese neuen create Methoden müsstest du auch hinzufügen. Generisch, one does it all, wie von den testfällen suggeriert, funktioniert nicht.

Parasiris
Windoof-User
Windoof-User
Beiträge: 30
Registriert: 1. Okt 2007 16:04

Re: ex05, Aufgabe 4

Beitrag von Parasiris »

Ok danke dir, wenn das erlaubt ist dann ist das nun klar.
Ich dachte halt, dass die Idee ist für alleAccounts die Tests zu erfüllen, aber das kann irgendwie ncht funktionieren.

Toobee
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 225
Registriert: 7. Apr 2011 12:58

Re: ex05, Aufgabe 4

Beitrag von Toobee »

Ja, das war auch unser Problem, aber Marcel hats ja selbst gesagt:
marcel_b hat geschrieben:die tests dürfen verändert werden - und müssen u.U. sogar verändert werden( je nachdem wie ihr euer neues LSP und DbC konformes Design bauen möchtet.)

Antworten

Zurück zu „Archiv“