JUnit 4 Vs TestNG - Vergleich
JUnit 4 und TestNG sind beide sehr beliebte Unit-Test-Frameworks in Java. Beide Frameworks sehen in ihrer Funktionalität sehr ähnlich aus. Welches ist besser? Welches Unit-Test-Framework soll ich in einem Java-Projekt verwenden?
Hier habe ich einen Funktionsvergleich zwischen JUnit 4 und TestNG durchgeführt.
1. Anmerkungsunterstützung
Die Annotation-Unterstützungen sind sowohl in JUnit 4 als auch in TestNG implementiert und sehen ähnlich aus.
| Feature | JUnit 4 | TestNG |
|---|---|---|
Testanmerkung |
@Prüfung |
@Prüfung |
Führen Sie diese aus, bevor alle Tests in dieser Suite ausgeführt wurden |
— |
@BeforeSuite |
Ausführen, nachdem alle Tests in dieser Suite ausgeführt wurden |
— |
@ AfterSuite |
vor dem Test laufen lassen |
— |
@BeforeTest |
nach dem Test laufen |
— |
@ AfterTest |
Ausführen, bevor die erste Testmethode aufgerufen wird, die zu einer dieser Gruppen gehört |
— |
@BeforeGroups |
Wird ausgeführt, nachdem die letzte Testmethode aufgerufen wurde, die zu einer dieser Gruppen gehört |
— |
@ AfterGroups |
Ausführen, bevor die erste Testmethode in der aktuellen Klasse aufgerufen wird |
@Vor dem Unterricht |
@Vor dem Unterricht |
Wird ausgeführt, nachdem alle Testmethoden in der aktuellen Klasse ausgeführt wurden |
@Nach dem Unterricht |
@Nach dem Unterricht |
vor jeder Testmethode ausführen |
@Vor |
@BeforeMethod |
Nach jeder Testmethode ausführen |
@Nach |
@ AfterMethod |
Test ignorieren |
@ignorieren |
@Test (enbale = false) |
erwartete Ausnahme |
@Test (erwartet = ArithmeticException.class) |
@Test (expectedExceptions = ArithmeticException.class) |
Auszeit |
@ Test (Timeout = 1000) |
@ Test (Timeout = 1000) |
Die Hauptanmerkungsunterschiede zwischen JUnit4 und TestNG sind
1. In JUnit 4 müssen wir die Methoden "@BeforeClass" und "@AfterClass" als statische Methode deklarieren. TestNG ist flexibler in der Methodendeklaration, es gibt diese Einschränkungen nicht.
2. 3 zusätzliche SetUp / TearDown-Ebene: Suite und Gruppe (@ Before / AfterSuite, @ Before / AfterTest, @ Before / AfterGroup). Weiteredetail here. anzeigen
JUnit 4
@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
System.out.println("@BeforeClass - oneTimeSetUp");
}
TestNG
@BeforeClass
public void oneTimeSetUp() {
// one-time initialization code
System.out.println("@BeforeClass - oneTimeSetUp");
}
In JUnit 4 ist die Namenskonvention für Anmerkungen etwas verwirrend, z. B. "Vorher", "Nachher" und "Erwartet". Wir verstehen nicht wirklich, was "Vorher" und "Nachher" tun und was wir vom Test "erwarten" Methode? TestiNG ist einfacher zu verstehen und verwendet stattdessen "BeforeMethod", "AfterMethod" und "ExpectedException".
2. Ausnahmetest
Der „Ausnahmetest“ bedeutet, welche Ausnahme vom Komponententest ausgelöst wird. Diese Funktion ist sowohl in JUnit 4 als auch in TestNG implementiert.
JUnit 4
@Test(expected = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}
TestNG
@Test(expectedExceptions = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}
3. Test ignorieren
"Ignoriert" bedeutet, ob der Komponententest ignoriert werden soll. Diese Funktion ist sowohl in JUnit 4 als auch in TestNG implementiert.
JUnit 4
@Ignore("Not Ready to Run")
@Test
public void divisionWithException() {
System.out.println("Method is not ready yet");
}
TestNG
@Test(enabled=false)
public void divisionWithException() {
System.out.println("Method is not ready yet");
}
4. Zeittest
Der „Zeittest“ bedeutet, dass, wenn ein Komponententest länger als die angegebene Anzahl von Millisekunden dauert, der Test beendet wird und als fehlgeschlagen markiert wird. Diese Funktion ist sowohl in JUnit 4 als auch in TestNG implementiert.
JUnit 4
@Test(timeout = 1000)
public void infinity() {
while (true);
}
TestNG
@Test(timeOut = 1000)
public void infinity() {
while (true);
}
5. Suite Test
Der „Suite-Test“ bedeutet, einige Unit-Tests zu bündeln und gemeinsam auszuführen. Diese Funktion ist sowohl in JUnit 4 als auch in TestNG implementiert. Beide verwenden jedoch sehr unterschiedliche Methoden, um dies zu implementieren.
JUnit 4
Mit "@RunWith" und "@Suite" wird der Suite-Test ausgeführt. Die folgende Klasse bedeutet, dass sowohl der Komponententest "JunitTest1" als auch "JunitTest2" nach Ausführung von JunitTest5 zusammen ausgeführt werden. Die gesamte Deklaration wird innerhalb der Klasse definiert.
@RunWith(Suite.class)
@Suite.SuiteClasses({
JunitTest1.class,
JunitTest2.class
})
public class JunitTest5 {
}
TestNG
Die XML-Datei wird zum Ausführen des Suite-Tests verwendet. Die folgende XML-Datei bedeutet, dass sowohl der Komponententest "TestNGTest1" als auch "TestNGTest2" zusammen ausgeführt werden.
TestNG kann mehr als nur das Testen von Klassen bündeln, es kann auch das Testen von Methoden bündeln. Mit dem einzigartigen „Grouping“ -Konzept von TestNG ist jede Methode an eine Gruppe gebunden und kann Tests nach Merkmalen kategorisieren. Zum Beispiel,
Hier ist eine Klasse mit vier Methoden, drei Gruppen (Methode1, Methode2 und Methode3)
@Test(groups="method1")
public void testingMethod1() {
System.out.println("Method - testingMethod1()");
}
@Test(groups="method2")
public void testingMethod2() {
System.out.println("Method - testingMethod2()");
}
@Test(groups="method1")
public void testingMethod1_1() {
System.out.println("Method - testingMethod1_1()");
}
@Test(groups="method4")
public void testingMethod4() {
System.out.println("Method - testingMethod4()");
}
Mit der folgenden XML-Datei können wir den Komponententest nur mit der Gruppe "method1" ausführen.
Mit dem Testkonzept „Gruppierung“ sind die Möglichkeiten für Integrationstests unbegrenzt. Zum Beispiel können wir nur die Gruppe "DatabaseFuntion" aus allen Unit-Test-Klassen testen.
6. Parametrisierter Test
Der „Parametrisierte Test“ bedeutet, dass der Parameterwert für den Komponententest variiert wird. Diese Funktion ist sowohl in JUnit 4 als auch in TestNG implementiert. Beide verwenden jedoch sehr unterschiedliche Methoden, um dies zu implementieren.
JUnit 4
Mit "@RunWith" und "@Parameter" wird der Parameterwert für den Komponententest angegeben. @Parameters muss List [] zurückgeben, und der Parameter wird als Argument an den Klassenkonstruktor übergeben.
@RunWith(value = Parameterized.class)
public class JunitTest6 {
private int number;
public JunitTest6(int number) {
this.number = number;
}
@Parameters
public static Collection data() {
Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
return Arrays.asList(data);
}
@Test
public void pushTest() {
System.out.println("Parameterized Number is : " + number);
}
}
Hier gibt es viele Einschränkungen. Wir müssen den Weg „JUnit“ befolgen, um den Parameter zu deklarieren, und der Parameter muss an den Konstruktor übergeben werden, um das Klassenmitglied als Parameterwert für das Testen zu initialisieren. Der Rückgabetyp der Parameterklasse ist "List []". Die Daten wurden zum Testen auf String oder einen primitiven Wert beschränkt.
TestNG
Eine XML-Datei oder "@DataProvider" wird verwendet, um verschiedene Parameter zum Testen bereitzustellen.
XML file for parameterized test.
Nur "@Parameters" deklariert in einer Methode, die Parameter zum Testen benötigt. Die Parameterdaten werden in den XML-Konfigurationsdateien von TestNG bereitgestellt. Auf diese Weise können wir einen einzelnen Testfall mit unterschiedlichen Datensätzen wiederverwenden und sogar unterschiedliche Ergebnisse erzielen. Darüber hinaus können auch Endbenutzer, QA oder QE ihre eigenen Daten in XML-Dateien zum Testen bereitstellen.
Gerätetest
public class TestNGTest6_1_0 {
@Test
@Parameters(value="number")
public void parameterIntTest(int number) {
System.out.println("Parameterized Number is : " + number);
}
}
XML-Datei
@DataProvider für parametrisierten Test.
Während das Abrufen von Datenwerten in eine XML-Datei sehr praktisch sein kann, erfordern Tests gelegentlich komplexe Typen, die nicht als Zeichenfolge oder primitiver Wert dargestellt werden können. TestNG behandelt dieses Szenario mit seiner Annotation @DataProvider, die die Zuordnung komplexer Parametertypen zu einer Testmethode erleichtert.
@DataProvider für Vektor, String oder Integer als Parameter
@Test(dataProvider = "Data-Provider-Function")
public void parameterIntTest(Class clzz, String[] number) {
System.out.println("Parameterized Number is : " + number[0]);
System.out.println("Parameterized Number is : " + number[1]);
}
//This function will provide the patameter data
@DataProvider(name = "Data-Provider-Function")
public Object[][] parameterIntTestProvider() {
return new Object[][]{
{Vector.class, new String[] {"java.util.AbstractList",
"java.util.AbstractCollection"}},
{String.class, new String[] {"1", "2"}},
{Integer.class, new String[] {"1", "2"}}
};
}
@DataProvider für Objekt als Parameter
P.S “TestNGTest6_3_0” ist ein einfaches Objekt mit einer Methode zum Festlegen der Demo.
@Test(dataProvider = "Data-Provider-Function")
public void parameterIntTest(TestNGTest6_3_0 clzz) {
System.out.println("Parameterized Number is : " + clzz.getMsg());
System.out.println("Parameterized Number is : " + clzz.getNumber());
}
//This function will provide the patameter data
@DataProvider(name = "Data-Provider-Function")
public Object[][] parameterIntTestProvider() {
TestNGTest6_3_0 obj = new TestNGTest6_3_0();
obj.setMsg("Hello");
obj.setNumber(123);
return new Object[][]{
{obj}
};
}
Der parametrisierte Test von TestNG ist sehr benutzerfreundlich und flexibel (entweder in einer XML-Datei oder innerhalb der Klasse). Es kann viele komplexe Datentypen als Parameterwert unterstützen und die Möglichkeit ist unbegrenzt. Als obiges Beispiel können wir sogar unser eigenes Objekt (TestNGTest6_3_0) für den parametrisierten Test übergeben
7. Abhängigkeitstest
Der „parametrisierte Test“ bedeutet, dass Methoden eine Testbasis für die Abhängigkeit sind, die vor einer gewünschten Methode ausgeführt wird. Wenn die abhängige Methode fehlschlägt, werden alle nachfolgenden Tests übersprungen und nicht als fehlgeschlagen markiert.
JUnit 4
Das JUnit-Framework konzentriert sich auf die Testisolierung. Diese Funktion wurde im Moment nicht unterstützt.
TestNG
Es verwendet "DependOnMethods", um die Abhängigkeitstests wie folgt zu implementieren
@Test
public void method1() {
System.out.println("This is method 1");
}
@Test(dependsOnMethods={"method1"})
public void method2() {
System.out.println("This is method 2");
}
Die "Methode2 ()" wird nur ausgeführt, wenn "Methode1 ()" erfolgreich ausgeführt wird, andernfalls überspringt "Methode2 ()" den Test.
Fazit
Nachdem ich alle Funktionsvergleiche durchdacht habe, schlage ich vor, TestNG als Kern-Unit-Test-Framework für Java-Projekte zu verwenden, da TestNG bei Parametrisierungstests, Abhängigkeitstests und Suite-Tests (Gruppierungskonzept) weiter fortgeschritten ist. TestNG ist für Tests auf hoher Ebene und komplexe Integrationstests gedacht. Seine Flexibilität ist besonders bei großen Testsuiten nützlich. Darüber hinaus deckt TestNG auch die gesamte Kernfunktionalität von JUnit4 ab. Es ist einfach kein Grund mehr für mich, JUnit zu verwenden.
Verweise
TestNG
———
http://en.wikipedia.org/wiki/TestNG
http://www.ibm.com/developerworks/java/library/j-testng/
http://testng.org/doc/index.html
http://beust.com/weblog/