Seite 1 von 1

E-Techniker-Fragensammlung

Verfasst: 19. Nov 2009 17:50
von moritz
So wie der Name schon sagt, werde ich hier mal einen Thread erstellen wo wir E-Techniker alle Fragen stellen die wir so während jeder Übung ansammeln. Kann also voll werden.

Da wir mit JUnit noch nie wirklich gearbeitet haben gab es da auch gleich ein Problem:

Zum testen dieser Methode:

Code: Alles auswählen

	private FlugBuchungsService flugbuchungsService;

	public void verbindeFlugBuchungsService(FlugBuchungsService flugBuchungsService)
	{
		this.flugbuchungsService = flugBuchungsService;
aus der Klasse Beratungssystem, haben wir folgenden Code geschrieben:

Code: Alles auswählen

@Test
	
	public void verbindeFlugBuchungsServiceTest (){
		
		Beratungssystem b = new Beratungssystem();
		b.verbindeFlugBuchungsService(new FlugBuchungsService());
		
		assertNull("testBuchungsService wurde an Klassenattribut übergeben", b.flugbuchungsService);
		
	}
Ersten würde ich gerne wissen ob das Vorgehen generell richtig ist und zweitens besteht das Problem, dass wir das Attibut b.flugbuchungsService nicht auslesen können, weil es als private implementiert ist. Gibt es eine Möglichkeit trotzdem ein Test zu schreiben, welche die Funktionalität von "verbindeFlugBuchungsService" prüft oder ist dies aufgrund der private-Implementierung garnicht möglich und wir sollen nur die public Methoden bzw. Attribute/Objekte prüfen.

Re: E-Techniker-Fragensammlung

Verfasst: 19. Nov 2009 19:03
von Sebastian Hartte
moritz hat geschrieben:Ersten würde ich gerne wissen ob das Vorgehen generell richtig ist und zweitens besteht das Problem, dass wir das Attibut b.flugbuchungsService nicht auslesen können, weil es als private implementiert ist. Gibt es eine Möglichkeit trotzdem ein Test zu schreiben, welche die Funktionalität von "verbindeFlugBuchungsService" prüft oder ist dies aufgrund der private-Implementierung garnicht möglich und wir sollen nur die public Methoden bzw. Attribute/Objekte prüfen.
Private Attribute kannst du prinzipiell von außen nicht abrufen. Ich kenne die Aufgabe nicht, aber gibt es eine getFlugbuchungsService() Methode, die Dir vielleicht das Attribut nach außen reicht? Falls ja, kannst du ja zum Beispiel diese Methode benutzen.
Der Testfall sieht prinzipiell okay aus, wenn du es noch etwas genauer haben möchtest, solltest du lieber prüfen ob b.flugbuchungsService wirklich das selbe Objekt ist, das du an verbindeFlugBuchungsService übergeben hast. (Siehe assertSame). Im moment prüfst du ja nur, ob nach verbindeFlugBuchungsService *irgendwas* in b.flugbuchungsService steht.

Gruß,
Sebastian

Re: E-Techniker-Fragensammlung

Verfasst: 19. Nov 2009 19:15
von Tobias
moritz hat geschrieben:Ersten würde ich gerne wissen ob das Vorgehen generell richtig ist
Denke schon. Man kann sich natürlich darüber streiten, ob es sinnvoll ist, triviale Methoden (getter/setter) zu testen. Davon abgesehen solltest hier eher assertNotNull statt assertNull oder eben assertSame benutzen.
zweitens besteht das Problem, dass wir das Attibut b.flugbuchungsService nicht auslesen können, weil es als private implementiert ist. Gibt es eine Möglichkeit trotzdem ein Test zu schreiben
Spontan fallen mir mehrere Möglichkeiten ein:
  • Alles über Kapselung vergessen und das Attribut public machen. Dafür wird man aber in der Regel geschlachtet. ;)
  • Die Testfälle in dieselbe Klasse stopfen. Das ist allerdings auch nicht besser. :roll:
  • Viel besser ist es, eine (public) Getter-Methode zu benutzen, die (meistens) einfach nur "return flugbuchungsService" enthält. Oft brauchen nämlich nicht nur die Tests, sondern auch andere Module Zugriff darauf, so dass man die Methode sowieso schon hat.
  • Manchmal kann so ein Getter aber auch unerwünscht sein. Dann kann man das Attribut bzw. die Getter-Methode nur im aktuellen Paket sichtbar machen, d.h. weder public noch protected noch private benutzen, sondern einfach gar nichts angeben. Für andere Klassen außerhalb des Pakets ist der Zugriff dann wie bei private verboten, innerhalb des Pakets aber wie bei public erlaubt. Wenn der Testfall dann in demselben Paket liegt, gibt es daher keine Zugriffsprobleme. Das kann ein brauchbarer Kompromiss sein, da "eigene" Klassen nicht behindert werden, "fremde" aber nichts kaputt machen können. (Der Testfall muss übrigens nicht unbedingt in demselben Verzeichnis liegen, da man den Quelltext der Pakete auf mehrere Verzeichnisse aufteilen kann.)
Falls kein geeigneter Getter existiert und die Klasse Beratungssystem auch nicht verändert werden kann, wirst du an den flugbuchungsService allerdings nicht herankommen.

Re: E-Techniker-Fragensammlung

Verfasst: 19. Nov 2009 22:50
von moritz
Ok,

also da ich keine get-Methode habe und das Programm auch nicht einfach unschreiben kann, zumindest geh ich davon jetzt mal aus, werde ich die private-Attribute nicht weiter untersuchen.

Danke jedenfalls für die Antworten. Wird sicherlich nicht die letzte Frage bleiben.

Re: E-Techniker-Fragensammlung

Verfasst: 22. Nov 2009 03:11
von grek40
Ich bin mir grad nichtmal sicher, ob die Methode überhaupt explizit getestet werden muss, oder ob sie schon vorgegeben war.

Jedenfalls würde ich sie einfach im @Before beim initialisieren nutzen, da sie ja Voraussetzung für viele andere Tests ist - frei nach dem Motto 'Code Coverage erreicht, egal ob die Ausführung wirklich ein Test war' und 'Wenns Fehler gibt dann wird mans schon an den Folgefehlern der anderen Methoden bemerken'

Re: E-Techniker-Fragensammlung

Verfasst: 1. Dez 2009 20:34
von moritz
hallo zusammen,
wir haben wieder ne frage zur aktuellen übung, also zur exercise 06. wir habern unsere login methoden geschrieben und mit der main methode getestet. funktioniert alles super.
das problem ist dass die junits test irgendwelche "java.lang.NumberFormatException: null" auswerfen die uns aus unserem eigenen code heraus unerklärlich bleiben und deshalb irgendwas mit der simcard klasse zu tun haben müssen. ging das noch irgendjemanden so und kann uns jemand erklären wie so ein fehler zu stande kommen kann? im prinzip ist der PIN doch einfach ein string in den ich wenn ich lust hätte auch buchstaben statt den üblichen zahlen schreiben könnte, oder is das durch diese "Properties" nicht möglich? Was ist das eigentlich genau, also diese "Properties" und warum macht es sinn, diese statt einfachen attributen zu nutzen?
vielen dank im vorraus

Re: E-Techniker-Fragensammlung

Verfasst: 1. Dez 2009 21:00
von Sebastian Hartte
moritz hat geschrieben:hallo zusammen,
wir haben wieder ne frage zur aktuellen übung, also zur exercise 06. wir habern unsere login methoden geschrieben und mit der main methode getestet. funktioniert alles super.
das problem ist dass die junits test irgendwelche "java.lang.NumberFormatException: null" auswerfen die uns aus unserem eigenen code heraus unerklärlich bleiben und deshalb irgendwas mit der simcard klasse zu tun haben müssen. ging das noch irgendjemanden so und kann uns jemand erklären wie so ein fehler zu stande kommen kann? im prinzip ist der PIN doch einfach ein string in den ich wenn ich lust hätte auch buchstaben statt den üblichen zahlen schreiben könnte, oder is das durch diese "Properties" nicht möglich? Was ist das eigentlich genau, also diese "Properties" und warum macht es sinn, diese statt einfachen attributen zu nutzen?
vielen dank im vorraus
Hi,

an welcher Code-Stelle tritt denn die Exception genau auf?
Habt ihr den Test mal mit dem Debugger eurer IDE gestartet um dazu mehr herauszufinden?

Gruß,
Sebastian

Re: E-Techniker-Fragensammlung

Verfasst: 2. Dez 2009 12:45
von m_schulz
@moritz:
Warum machst du für deine Fragen eigentlich eine extra Gruppe auf? Kannst du nicht wie alle anderen auch als Betreff des Threads die Aufgabe nennen auf die sich die Frage bezieht? So stehen die Etechniker wieder wie die letzen Deppen dar! E-Techniker-Fragensammlung ist einach ein vollkommen sinnloser Titel, der nichts über den Inhalt der Fragen aussagt, sondern nur die Gruppe einschränkt, die es angeblich angeht. Es könnte ja auch Leute aus anderen Studiengängen geben, die die gleichen Fragen haben. Bestimmt bist du auch der der sich beim Prof beschwert, wenn man in einer Software Engineering veranstaltung etwas implementieren muss.

@all:
ich wäre dafür diesen Thread zu schließen, so dass es keine extrawurst mehr für die etechniker gibt.

Re: E-Techniker-Fragensammlung

Verfasst: 2. Dez 2009 15:06
von moritz
@sebastian:

hatte gestern noch eine Weile rumprobiert und es lag letztendlich daran, dass es eine vorgefertigte Datei-Properties gab, auf die alle in unserem Test erstellten Klassen ungewollte zugegriffen haben. Dabei wurde der Inhalt einiger Attribute auf 'null' gesetzt. Die Methoden, die auf diese Attribute Zugriff hatten, scheiterten an dem Punkt wo der erwartete Integer-Inhalt in einen String umgewandelt werden sollte.

Hab deinen Beitrag gestern nicht mehr gelesen, aber trozdem danke!

@m_schulz:

Ich hoffe du kannst trotz diesem Missstand heute nacht ruhig schlafen.

Re: E-Techniker-Fragensammlung

Verfasst: 2. Dez 2009 15:35
von heXagon
moritz hat geschrieben: @m_schulz:

Ich hoffe du kannst trotz diesem Missstand heute nacht ruhig schlafen.
Er hat schon recht, es ist ja nicht zwangsläufig so, dass ihr andere Probleme als die anderen Studenten habt.

Gruß Martin

Re: E-Techniker-Fragensammlung

Verfasst: 2. Dez 2009 15:52
von moritz
Ich habe mit der Meinung auch kein Problem. Von mir aus können wir demnächst auch neue Themen eröffnen. Man kann es allerdings auch anmerken ohne irgendwelche wahrlosen Behauptungen dran zu hängen. Ebenso sinnvoll wie ein passender Threadtitel, wäre wohl ein angemessenes Beitragsniveau.

Fakt: Demnächst gibt es neue Threads.

Re: E-Techniker-Fragensammlung

Verfasst: 2. Dez 2009 19:18
von heXagon
Um diesen Thread dann tatsächlich zum Ende zu führen:

Du erhälst deine Exception ("java.lang.NumberFormatException: null"), weil du mit Integer.parseInt() auf einem Nullpointer operierst. Ursprung des Ganzen ist die Tatsache, dass geschickterweise die Methode, die in der Simkarte die Properties lädt bei einem Ladefehler die Exception Message gar nicht erst ausgibt, sondern schlicht false zurückwirft.

Gruß Martin