2016-04-13 6 views
0

Ich habe Java-Code, der JAR verwendet:Wie kann ich Java-Code testen, der JAR verwendet?

public class Version { 
    public String getVersion() { 
     // Use Java Package API to return information specified in the manifest of this JAR. 
     return getClass().getPackage().getImplementationVersion(); 
    } 
} 

Wie führe ich JUnit-Test für diesen Code?

Es schlägt in der Entwicklung (in Eclipse) fehl, da es noch keine JAR-Datei gibt.

Es scheitert in Produktions-Build (in Gradle), da es noch keine JAR-Datei gibt.

+1

Sie würden es verspotten. –

+2

Was testen Sie? Wenn Sie Clients dieser Methode testen, verbinden Sie geeignete Mocks der enthaltenen Klasse oder einer Schnittstelle, die sie implementiert. Wenn Sie die Implementierung der Methode testen, können Sie überprüfen, ob sie entweder null ist oder einem erwarteten Muster entspricht. Wenn Sie 'getImplementationVersion()' selbst testen, dann hören Sie auf - es ist ein Drittanbieter-Code, vermutlich mit eigenen Tests. –

Antwort

1

Sie müssen immer die Abhängigkeiten für Ihre Komponententests verspotten. Grenze ist Unit Test dein Code und nicht das Glas selbst. Mockito Framework ist gut und es gibt andere Frameworks, die die Arbeit machen.

1

Es besteht die Möglichkeit, dass dies nicht richtig verspottet werden kann (und somit: nicht getestet werden). Der Punkt ist, dass Sie tatsächlich eine Methode für "das" aufrufen. Aber du kannst ein Objekt nicht testen ... und es gleichzeitig verspotten.

Sie sehen, wenn Sie Ihre Produktion Code würde wie folgt aussehen:

public String getVersion() { 
    return someObject.getClass()..... 
} 

dann könnte man ein Mock-Objekt erstellen; und fügen Sie das in Ihre Versionsklasse ein. Aber selbst dann ist die Methode getClass() endgültig in java.lang.Object; und deshalb kannst du es sowieso nicht verspotten.

[Angemessene spöttische Frameworks wie EasyMock oder Mokito funktionieren, indem Sie Klassen erweitern und die Methoden überschreiben, die Sie steuern möchten. Es gibt Frameworks wie PowerMock, die Byte-Code-Manipulation machen und diese Art von Spott erlauben - aber Sie sollten niemals solche Bibliotheken verwenden. wie sie wirklich schlechte Nebenwirkungen haben (wie die meisten Abdeckung Bibliotheken brechen)]

Was funktionieren könnte:

class Version { 
    private final Package packageForVersionCheck; 

    public Version() { 
     this(getClass().getPackage())); 
    } 
    Version(Package somePackage) { 
     this.packageForVersionCheck = ... 
    } 

    public String getVersion() { 
     return this.packageForVersionCheck.getImpl.... 

Jetzt können Sie Dependency Injection verwenden, um eine „verspottet“ Paket zur Verfügung zu stellen, die diese Zeichenfolge zurückgibt. Aber gut, das sieht nach einer Menge Code für fast keinen Gewinn aus.

Lange Rede, kurzer Sinn: Manchmal kann man einfach keinen vernünftigen Komponententest schreiben. Dann machen Sie die nächstbeste Sache: Erstellen Sie einen "funktionalen" Test, der automatisch in einem "kundenähnlichen" Setup ausgeführt wird; und stellen Sie sicher, dass Sie über ein automatisches Setup verfügen, um auch solche Tests durchzuführen.

Verwandte Themen