Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Gleiche JUnit-Tests automatisert mit verschiedenen Methoden ausführen
also erstmal grundsätzlich würde ich mir sehr genau überlegen, ob ich getter/setter überhaupt teste....
Bei Deinem ersten setter ist die Frage was für fälle vorkommen können ? (setXXX (null) ?) und dann ?
Aber bei Deinem Getter habe ich ernste bedenken, da Du hier nicht den getter testest sondern mehr ob der Compiler bzw. die JVM hier eine Runtime Exception wirft....
Die Frage ist, ob Du das tatsächlich testen möchtest?
Oder geht es hier um andere Dinge?
Kannst Du vielleicht einen kleinen Code-Abschnitt (setter/getter) angeben, dann kann man vielleicht eher darauf antworten ?
Naja, wenn ich möchte einfach dafür sorgen, dass kein Nullpointer übergeben wird. Und eine IllegalArgumentException ist doch aufschlussreicher als eine NullpointerException, oder täusche ich mich da?
Aber bei Deinem Getter habe ich ernste bedenken, da Du hier nicht den getter testest sondern mehr ob der Compiler bzw. die JVM hier eine Runtime Exception wirft....
Die Frage ist, ob Du das tatsächlich testen möchtest?
Nun, ich möchte eine Exception werfen, damit im Fehlerfall erkennbar ist, wo ein Zustand herrscht, der nicht sein dürfte, anstatt an einer ganz anderen Stelle eine NullpointerException zu bekommen, die dann wohl weniger aussagekräftig ist.
Das Hauptziel ist die Softwarequalität/Stabilität/Zuverlässigkeit zu erhöhen. Hierzu versuche ich zu verstehen, wie das Fehlerhandling sinnvoll gestaltet werden kann. Siehe hierzu auch meine erste Frage: Fehlerhandling bei POJOs
Nachdem ich hin und wieder NullpointerExceptions zur Laufzeit bekam, die zunächst nicht so einfach zu deuten waren, fing ich an, bereits beim Setten/Getten Exceptions zu werfen, da ich somit sehr schnell sehen konnte, wo das Problem ist.
Vielleicht bin ich damit aber auch auf dem Falschen Wege?!
Hier ist ein Beispiel einer Nachricht, bei der der Header immer gesetzt sein sollte:
Java:
public class BasicMessageImpl implements BasicMessage{
private byte[] userData = null;
private BasicHeader header = null;
@Override
public byte[] getData() {
if(userData == null){
throw new IllegalStateException("No user data has been set");
}
return userData;
}
@Override
public void setData(byte[] data) {
if( data == null ){
throw new IllegalArgumentException("Data must not be null!");
}
this.userData = data;
}
@Override
public BasicHeader getBasicHeader() {
if(this.header == null){
throw new IllegalStateException("Message header was not set");
}
return this.header;
}
@Override
public void setBasicHeader(BasicHeader h) {
if( h == null ){
throw new IllegalArgumentException("Data must not be null!");
}
this.header = h;
}
}
Naja, wenn ich möchte einfach dafür sorgen, dass kein Nullpointer übergeben wird. Und eine IllegalArgumentException ist doch aufschlussreicher als eine NullpointerException, oder täusche ich mich da?
Nun, ich möchte eine Exception werfen, damit im Fehlerfall erkennbar ist, wo ein Zustand herrscht, der nicht sein dürfte, anstatt an einer ganz anderen Stelle eine NullpointerException zu bekommen, die dann wohl weniger aussagekräftig ist.
Meist steht eine NPE nicht alleine und hat auch einen "caused by..." Teil mit dem man dem Problem meist sehr schnell auf die schliche kommt....ich gebe Dir allerdings recht, dass einen Entsprechende Exception hier aufschlussreicher wäre...
flossy hat gesagt.:
Das Hauptziel ist die Softwarequalität/Stabilität/Zuverlässigkeit zu erhöhen. Hierzu versuche ich zu verstehen, wie das Fehlerhandling sinnvoll gestaltet werden kann. Siehe hierzu auch meine erste Frage: Fehlerhandling bei POJOs
Nachdem ich hin und wieder NullpointerExceptions zur Laufzeit bekam, die zunächst nicht so einfach zu deuten waren, fing ich an, bereits beim Setten/Getten Exceptions zu werfen, da ich somit sehr schnell sehen konnte, wo das Problem ist.
Vielleicht bin ich damit aber auch auf dem Falschen Wege?!
Das Thema für Gründe etc. zu Unit Tests brauchen wir nicht zu diskutieren...
flossy hat gesagt.:
Java:
public class BasicMessageImpl implements BasicMessage{
private byte[] userData = null;
private BasicHeader header = null;
@Override
public byte[] getData() {
if(userData == null){
throw new IllegalStateException("No user data has been set");
}
return userData;
}
@Override
public void setData(byte[] data) {
if( data == null ){
throw new IllegalArgumentException("Data must not be null!");
}
this.userData = data;
}
@Override
public BasicHeader getBasicHeader() {
if(this.header == null){
throw new IllegalStateException("Message header was not set");
}
return this.header;
}
@Override
public void setBasicHeader(BasicHeader h) {
if( h == null ){
throw new IllegalArgumentException("Data must not be null!");
}
this.header = h;
}
}
Dabei wäre meine Frage: Warum hat die Implementation keinen Konstruktor ? Oder war das nur exemplarisch gedacht ?
Weiterhin wäre die Frage: Wie bekommt die Klasse Ihre Werte? Per Spring (IoC) ? Wenn nicht könnte man die Datenübergabe im Konstruktor machen und dann im Konstruktor die Tests machen und somit die Getter/Setter vereinfachen....oder man eliminiert die Setter ganz (Werden die Setter überhaupt benötigt ?)...?
Weiterhin kommt mir dabei der Gedanke, dass Du ja gegen ein Interface implementiert hast. Da wäre zu bemerken, dass ein Interface ja eine Abmachung darstellt. Das Problem, dass dabei auftaucht ist, dass Du jetzt für jede Implementierung die ganzen Implementierungen Testen musst....je mehr Implementierung Du hast desto mehr Tests schreibst Du und vor allem der Test Code ist faktisch immer identisch....Das könnte man vereinfachen, in dem man eine Abstrakte Klasse mit den Tests schreibt und für die implementationen ableitet und dort eine Methode überschreibt, die eine Instanz der jeweiligen Implementierung liefert...das Reduziert die Arbeit und vor allem schreibt man keinen Code doppelt (DRY)...
Eine weitere Frage ist, dass bei der Verwendung eines getters der Nutzer eigentlich ja mit den Rückgaben oder auch nicht Rückgaben (null) zurecht kommen muss...(siehe auch Interface Vereinbarung)....Das bedeutet meiner Meinung nach, dass man hier den Nutzer Testen muss, ob der mit den entsprechenden Rückgaben aus dem Objekt klar kommt oder nicht....Hängt aber auch von der Anwendung ab....Hier kommt man leicht zu dem Thema Mocking/Stubs etc.
Nein, die Werte werden "manuell" gesetzt. Spring möchte ich nicht verwenden, wobei IoC an sich vielleicht möglich wäre, doch da kenne ich mich noch nicht so gut aus.
Hmm...nein, eigentlich nicht, wenn ich ja jetzt mit dem Konstruktor die Daten setzte. Wenn ich jedoch auf die Idee kommen sollte, im Nachhinein den Header zu wechseln, dann muss ich Folgendes machen:
Weiterhin kommt mir dabei der Gedanke, dass Du ja gegen ein Interface implementiert hast. Da wäre zu bemerken, dass ein Interface ja eine Abmachung darstellt. Das Problem, dass dabei auftaucht ist, dass Du jetzt für jede Implementierung die ganzen Implementierungen Testen musst....je mehr Implementierung Du hast desto mehr Tests schreibst Du und vor allem der Test Code ist faktisch immer identisch....Das könnte man vereinfachen, in dem man eine Abstrakte Klasse mit den Tests schreibt und für die implementationen ableitet und dort eine Methode überschreibt, die eine Instanz der jeweiligen Implementierung liefert...das Reduziert die Arbeit und vor allem schreibt man keinen Code doppelt (DRY)...
Eine weitere Frage ist, dass bei der Verwendung eines getters der Nutzer eigentlich ja mit den Rückgaben oder auch nicht Rückgaben (null) zurecht kommen muss...(siehe auch Interface Vereinbarung)....Das bedeutet meiner Meinung nach, dass man hier den Nutzer Testen muss, ob der mit den entsprechenden Rückgaben aus dem Objekt klar kommt oder nicht....
Könnte man vielleicht sagen, Setter werfen im Fehlerfall Exceptions und jegliche Nutzer der Objekte müssen auf den Umgang mit fehlerhaften Werten getestet werden (also quasi anstatt den Exceptions bei den Gettern )?
Du kannst das gewünschte relativ einfach mit Reflection realisieren. Dann musst Du nicht jeden Setter manuell testen. Einfach alle Methoden der Klasse durchgehen und falls Setter, dann Aufruf der Methode mit null Parameter + entsprechendes assert.