Übung 12 (verfrüht) online

[Krümelmonster]

ist es aber wohl auch nicht schlimm

Ich nehme an, das bezieht sich auf meine erste Frage.
Also kann die AirplaneTest Klasse wohl doch nicht leer bleiben.

//edit
In Aufgabe 5.2 sollen also alle Abfragen mittels assertEquals() implementiert werden,
während in Aufgabe 5.3 die Abfragen mit @Test(expected = ...) implementiert werden sollen!?

//edit2
Gilt es auch als Abfrage, wenn man einfach nur Methoden aufruft und dann sagt:
Wenn es nicht ginge, dann würde eine Exception geworfen werden?

[guido]

In Aufgabe 5.2 sollen also alle Abfragen mittels assertEquals() implementiert werden,
während in Aufgabe 5.3 die Abfragen mit @Test(expected = ...) implementiert werden sollen!?

Das ist kein Widerspruch! Auch im Fall von Exceptions kann das Ergebnis mit "assertEquals" getestet werden, nur dass man hier an sich schon davon ausgehen sollte, dass das Ergebnis eine Exception ist.

Gilt es auch als Abfrage, wenn man einfach nur Methoden aufruft und dann sagt:
Wenn es nicht ginge, dann würde eine Exception geworfen werden?

Naja, eher nicht...

Guido

[Krümelmonster]

D.h. es kann z.B. auch so auf Exceptions getestet werden?
assertEquals(setLocation("Budapest"), AirborneComputerException);

Dann würde es allerdings möglich sein, zwei Abfragen hintereinander zu
schreiben, wobei beide eine Exception werfen können...

//edit
Wie soll ich eigentlich mit assertEquals() die Methode
deleteAirport() testen? Wenn sie funktioniert, gibt sie
ja nichts zurück.

Und mit assertEquals() kann man wohl nicht auf Exceptions testen
(oder ich weiß einfach nicht wie).

[sge]

genau vor den gleichen Problemen steh' ich auch Krümelmonster.

Mal eine allgemeine Frage zum Testen:
Soll man bei Testen auch in Lage gezwungen werden,
die zu testende Klasse mit verschiedenen Methoden zu erweitern,
nur damit man die Tests durchführen kann?

[Stumpf.Alex]

Unabhängig von der Übung meine Antwort: Soweit wie ich mich erinnern kann, gab es zum Thema testen den Stichpunkt Testtreiber, der beinhaltet eine Testumgebung für das zu testende Programm zu schaffen. Außerdem halte ich das im beschränkte Maße sinnvoll, da man ja so früher den Code testen kann, was ja in der Vorlesung als wünschenswert angesehen wurde.

[guido]

D.h. es kann z.B. auch so auf Exceptions getestet werden?
assertEquals(setLocation("Budapest"), AirborneComputerException);

Dann würde es allerdings möglich sein, zwei Abfragen hintereinander zu
schreiben, wobei beide eine Exception werfen können...

Ja, man kann mehreres auf einmal testen. Allerdings kriegt man (außer bei passender Fehlermeldung der Exception) auf die Art nicht heraus, woher die (erwartete?) Exception kam. Hier muss man also abwägen.

Wie soll ich eigentlich mit assertEquals() die Methode deleteAirport() testen? Wenn sie funktioniert, gibt sie ja nichts zurück.

Das geht mir assertEquals entsprechend nicht. Tipp: wenn ich zu vorher gelöschten Flughafen fliegen will, sollte eine Exception kommen.

Guido

[Krümelmonster]

Ja, man kann mehreres auf einmal testen. Allerdings kriegt man (außer bei passender Fehlermeldung der Exception) auf die Art nicht heraus, woher die (erwartete?) Exception kam. Hier muss man also abwägen.

Allerdings ist es die einzige Möglichkeit (oder jedenfalls die in der Übung erwünschte) Methode, um
zwei Methoden, die beide eine Exception werfen, hintereinander in einer einzigen Testmethode
testen zu können, oder?

Dann wollte ich noch auf Fehler auf den Folien 79, 80 und 81 in Foliensatz T19 hinweisen:

Code: Alles auswählen

Folie 79: assertEquals(calculator.getResult(), 2)
Folie 80:
assertEquals(calculator.getResult(), 8);
...
assertEquals(calculator.getResult(), 5);
Folie 81: assertEquals(calculator.getResult(), 100);

assertEquals ist so definiert, dass zuerst der Erwartungswert und dann die zu testende Methode aufgerufen wird.
Also müssten die Parameter getauscht werden (wie auf Folie 86):

Code: Alles auswählen

assertEquals(4, calculator.getResult());

Des weiteren würde mich mal interessieren, wie genau ich mit assertEquals() Exceptions abfangen kann.
Folgendes habe ich bisher versucht:
In der CalculatorTest.java (aus dem Testarchiv des Calculators von der Veranstaltungsseite) habe ich in der
divideByZero() Methode das calculator.divide(0); ersetzt durch assertEquals(ArithmeticException, calculator.divide(0));.
Allerdings mit dem Hinweis: ArithmeticException cannot be resolved
Auch ein import java.lang.ArithmeticException; am Anfang der Datei hat den Hinweis nicht geändert.
In den Folien habe ich dazu leider nichts gefunden.

[Stumpf.Alex]

Des weiteren würde mich mal interessieren, wie genau ich mit assertEquals() Exceptions abfangen kann.

Ganz einfach:

Code: Alles auswählen

try {
.....
assertEquals(0,0);
}
catch(...) {
...
assertEquals(0,1);
}

assertEquals ist so definiert, dass zuerst der Erwartungswert und dann die zu testende Methode aufgerufen wird.

Wo wird das definiert? Eigentlich ist es doch egal, ob du squareRoot(2)==4 oder 4==squareRoot(2) testest. Und ich habe bis jetzt nirgends etwas gefunden, bei dem man sich direkt von assertsEqual anzeigen lassen kann, welcher Wert falsch war.

[Krümelmonster]

Ganz einfach:

Code: Alles auswählen

try {
.....
assertEquals(0,0);
}
catch(...) {
...
assertEquals(0,1);
}

Antwort

assertEquals ist so definiert, dass zuerst der Erwartungswert und dann die zu testende Methode aufgerufen wird.

Wo wird das definiert? Eigentlich ist es doch egal, ob du squareRoot(2)==4 oder 4==squareRoot(2) testest. Und ich habe bis jetzt nirgends etwas gefunden, bei dem man sich direkt von assertsEqual anzeigen lassen kann, welcher Wert falsch war.

Wenn ein Test fehlschlägt, dann steht links: expected ... but was ...
Ausßerdem steht es so in der Doc.

[guido]

Des weiteren würde mich mal interessieren, wie genau ich mit assertEquals() Exceptions abfangen kann.

Sie sollen nicht "abgefangen", sondern willentlich verursacht werden durch entsprechende Abrufe. Statt "log2(-10)" kann ich entsprechendes auch mit "deleteAirport" machen, indem ich einen mir bekannt nicht vorhandenen Flughafen lösche - oder einen vorher gelöschten als Ziel nutze. Diese Methoden -- auch ganz ohne "assertEquals"! -- sollten dann mit @Test(expected=ExceptionTyp.class) "gefangen" werden.

Der Versuch mit dem Klassennamen scheitert so, weil nur Objekte genutzt werden können, keine Klassennamen. Wichtig in dem Kontext: bei "expected=" ist der Name als "ExceptionName.class" anzugeben, also nicht "ArithmeticException", sondern "ArithmeticException.class".

Guido

[Krümelmonster]

Ok, ich versuche nochmal meine ursprünglichen Probleme zu erläutern.

1. In Aufgabe 3 sollen wir die Exceptions der Methoden testen. Daraus schließe ich, dass wir in Aufgabe 2 die Methoden nur mit assertEquals() testen sollen.
Da ich aber deleteAirport() z.B. nur über die Exception von flyTo() testen kann, wäre das ein Widerspruch. Das bringt mich zu einem allgemeineren Problem.

2. In Aufgabe 3 sollen die Exceptions mit zwei Abfragen in einer Testmethode getestet werden. Sobald aber die erste Abfrage wie erwartet eine Exception
geworfen hat, die mit @Test(expected = ...class) gefangen wurde, wird danach die zweite Abfrage nicht mehr ausgeführt.

[Jo(h)nny]

müssen wir die hilfsprozeduren testen??(hoffentlich nicht:))

[Stumpf.Alex]

In der Aufgabe 2 heißt es:

Testen Sie auch ihre eigene Merhoden.

Falls du das meinst. Ansonsten halt alle Methoden, wie sie in der Hausübung aufgezählt werden.

[Stumpf.Alex]

Ja ich frage mich auch noch wie man eine setter Methode unabhängig einer getter Methode testen kann...wie z.B. bei setAirplane und getAirplane (soll ja laut Übung mit je zwei eigenen Tests geprüft werden).

Ich kann ja nur setAirplane testen, wenn ich mit getAirplane abfrage, ob das richtige Flugzeug abgespeichert wurde (aufgrund der Verkapselung kann ich ja nicht direkt auf das Flugzeugobjekt des Bordcomputers zugreifen). Aber dabei teste ich ja eher getAirplane bzw. der Test für getAirplane wäre ja das gleiche Schema, weshalb ich mich frage, wie man da jetzt die beiden Methoden, wie in der Übung erwünscht SINNVOLL differenziert testet?

Vor allem wird ja in der Übung 11 nicht verlangt, dass man Exceptions für set- und getAirplane auswirft..und da, wie von Krümelmonster genannt, ich die Aufgabe 2 genauso interpretiere, dass alle Tests mit assertEquals gemacht werden soll, frag ich mich um so mehr wie man das sinnvoll testen soll? Oder habe ich da etwas übersehen?

[Jo(h)nny]

nun ich hab jetzt bei fast jeder methode eine exception überprüft(also z.b. 2 mal ob die richtig funktioniert und 1 mal, ob sie die entsprechende exception wirft)
und die frage ist so gemeint, ich hab da eine methode, die sprit berechnet, und da wäre es nun wirklich überflussig 3 test zu dieser methode zu machen:)

aso fast vergessen, ich glaub nicht, dass man set methode ohne get-methode testen kann, und guido hat doch geschrieben, dass man deleteAirport über flyTo testen kann, also...