Gleiche JUnit-Tests automatisert mit verschiedenen Methoden ausführen

[flossy]

Ich habe einige POJOs, die ich mit JUnit automatisiert testen möchte.
Alle Setter möchte ich wie folgt testen:

@Test (expected = IllegalArgumentException.class )
public void setValueWithNullPointerThrowsException() {
   MyPOJO p = new MyPOJO();
   p.setValue(null);
}

und alle Getter so:

@Test (expected = IllegalStateException.class)
public void getValueOnUnsetThrowsException() {
   MyPOJO p = new MyPOJO();
   p.getValue();
}

Gibt es die Möglichkeit dies automatisiert zu machen oder muss ich für jede Methode einen eigenen Test manuell schreiben?

 

[kama]

Hallo,

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 ?

MfG
Karl Heinz Marbaise

 

[flossy]

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 ?

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.

Oder geht es hier um andere Dinge?

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?!

Kannst Du vielleicht einen kleinen Code-Abschnitt (setter/getter) angeben, dann kann man vielleicht eher darauf antworten ?

Hier ist ein Beispiel einer Nachricht, bei der der Header immer gesetzt sein sollte:

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;			
	}	
}

 

[kama]

Hallo,

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...

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...

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.

MfG
Karl Heinz Marbaise

 

[flossy]

Dabei wäre meine Frage: Warum hat die Implementation keinen Konstruktor ?

Hmm...stimmt, das wäre gar nicht schlecht einen zu erstellen ;-)

Weiterhin wäre die Frage: Wie bekommt die Klasse Ihre Werte? Per Spring (IoC) ?

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.

Wenn nicht könnte man die Datenübergabe im Konstruktor machen und dann im Konstruktor die Tests machen und somit die Getter/Setter vereinfachen....

ja das stimmt:

public BasicMessageImpl( BasicHeader h ){
	if( h == null ){
		throw new IllegalArgumentException("Basic header must not be null!");
	}
	this.header = h;
}

oder man eliminiert die Setter ganz (Werden die Setter überhaupt benötigt ?)...?

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:

BasicMessage basicMessageA = BasicMessageImpl(headerA);
// do something ...
// change header
BasicMessage basicMessageB = BasicMessageImpl(headerB);
basicMessageB.setData(basicMessageA.getData);
basicMessageA = basicMessageB;

anstatt einfach

BasicMessage basicMessageA = BasicMessageImpl(headerA);
// do something ...
// change header
basicMessageA.setHeader(headerB);

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)...

gute Idee! Das probiere ich gleich mal.

UPDATE: Es hat geklappt Danke!

public abstract class AbstractBasicMessageTest {

	private BasicMessage msg;
	
	public abstract BasicMessage getBasicMessage();

	@Before
	public void createMessage(){
		msg = getBasicMessage();
	}
	
	@Test
	public void setDataEqualsGetData() {	
		byte testData[] = new byte[4];
		testData[0] = 7;
		testData[3] = 0x0f;		
		msg.setData(testData);		
		assertEquals(testData,msg.getData());
	}

	@Test (expected = IllegalArgumentException.class)
	public void setDataWithNullThrowsException() {					
		msg.setData(null);					
	}
	
	@Test (expected = IllegalStateException.class)
	public void getDataOnUnsetThrowsException() {						
		msg.getData();					
	}
}

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....

Ja, damit wären wir wieder bei der Diskussion: Fehlerhandling bei POJOs

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 )?

 

[byte]

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.

 

[flossy]

Du kannst das gewünschte relativ einfach mit Reflection realisieren.

Ja, das ist eine Idee. etwa so?

@Test (expected = IllegalStateException.class)
public void testGetterOnUnsetData() throws Throwable {
	Method[] methods = msg.getClass().getMethods();
        for(Method m : methods){
		if(m.getName().contains("get")){
			try {
				m.invoke(msg, null);
			} catch (IllegalArgumentException e) {
				e.printStackTrace();
			} catch (IllegalAccessException e) {
				e.printStackTrace();
			} catch (InvocationTargetException e) {
				throw e.getTargetException();
			}		
		}
	}				
}