Übung 12 (verfrüht) online

[Jo(h)nny]

und vor allem, wie soll man in einem test mehrere exceptions testen????

[Krümelmonster]

Soll die Teilaufgabe 5.2 ausschließlich per assertEquals() gelöst werden?

Wie Dr. Rößling hier geschrieben hat, darf im Falle, dass die Methode nicht mit assertEquals() getestet werden kann,
auch eine Exception gewirfen werden.

Für die Funktionen, die eine Exception werfen, habe ich stattdessen @Test(expected=AirplaneException.class) verwendet, obwohl 5.3 ja dann überflüssig wäre. Denn einen Großteil der Funktionen, die eine Exception werfen, habe ich in 5.2 ja schon getestet.

Bei mir ist es so, dass eigentlich nur deleteAirport() in Aufgabe 5.2 mit Exceptions getestet werden muss.
Bei allen anderen Methoden habe ich (mehr oder weniger sinnvolle) Abfragen mit assertEquals() gefunden.

Ich habe meinem Tutor außerdem eine eMail mit der Frage geschickt, ob die von s!mon vorgeschlagene Kombination
von try..catch mit @Test(expected...), um beide Abfragen mit Exceptions testen zu können, akzeptiert wird.

[Osterlaus]

Wir sollen doch in AirborneComputerTest alle Funktionen testen, die wir da eingebaut haben. Und zum Beispiel die Funktion changeHeight wirft bei mir eine Exception, wenn ich die Flughöhe ungültig verändere. DeleteAirport wird eine Exception, wenn ich einen nicht vorhandenen Flughafen löschen will. FlyTo wirft eine Exception. gearDown wirft eine Exception. Und entweder fange ich die in den Testfunktionen ab oder werfe sie weiter nach außen, um bspw. mittels @Test(expected=AirplaneException.class) zu testen. Also muss ich doch in vielen Fällen so prüfen statt mit assertEquals - oder?

[Krümelmonster]

Ich nehme an, du beziehst dich auf Aufgabe 5.2.
Wenn die Methoden, die du benutzt, Exceptions werfen können, aber es mit deinen Eingaben nicht tun werden,
dann schreibst du diese Exceptions einfach an die Testmethode mittels throws ....
Die Methode flyTo() könntest du ja so testen, dass nach dem Aufruf, sich der Tankinhalt verändert haben muss z.B.
Du brauchst also, obwohl die Methoden Exceptions werfen können, diese nicht selbst zu fangen mittles try...catch.

[Krümelmonster]

Mein Tutor sagte, dass er die Lösung mit try...catch Blöcken wohl akzeptieren würde, dass das
aber keine Garantie ist, dass andere Tutoren es auch akzeptieren würden und deshalb jeder
selbst nachfragen müsste.

[mcdikki]

Ich habe das gelöst indem ich zwar mit try catch arbeite, aber trotzdem asser verwende.

Code: Alles auswählen

boolean ExceptionThrown = false;

try {
...mache was die Exception verursacht...;
} catch (ErwarteteException e) {
ExceptionThrows = true;
}

assert(ExceptionThrown);

So kann man auch in einer Methode beliebig viele Exceptions test.
Die letzte mache ich dann aber auch mit @Test (expected = Exception).


Aber irgendwie ist das schon nicht gut durchdacht. Testen sollte ja sinnvoll sein. Man könnte das wirklich schöner lösen als die Test der Exceptions von den Normalen zu lösen. Wenn ich eine Methode teste dann will ich doch alles an ihr testen und nicht nur teile.

[Krümelmonster]

Wie gesagt: Einfach den jeweiligen Tutor fragen, ob er/sie es so akzeptieren würde.

[crazy_wuschie]

Habe hier ein Eclipse-technisches Problem.

Aus welchem Grund sagt mir der Compiler in Eclipse ich müsse die Airplane-/Airport-/AirborneComputerExceptions abfangen beim JUnit Test?

Folgendes Konstrukt:

Code: Alles auswählen

@Test(expected = AirborneComputerException.class)
public void TestflyTo_er(){
   bc.flyTo("Hamburg");  //Hamburg ist nicht im Speicher
}

Anmerkung, bc ist ein mit @Before initalisierter Boardcomputer
Wenn ich keinen try, ctach block einführe und alle Exceptions abfange wird der Test nicht gestartet!

[mcdikki]

Ganz einfach, die Methoden sind mit "throws ExceptionXY" deklariert und daher musst du sie endweder fangen (try catch) oder weiterleiten mit "throws" im methoden Kopf.

lg mcdikki

[EDIT]

In deinem Fall solltest du sie nicht fangen, sonder mit throws weiterleiten, sonst geht dein @Test (expeted = Exception) nicht mehr.

[crazy_wuschie]

Danke.
Ich hab da wohl was verwechselt,
JUnit kümmert sich zwar um die geworfenen Exceptions, aber das heißt ja net dass ich Standard Java-Konstrukte einfach weglassen kann