Why we use TestNG instead of JUnit?

Why we use TestNG instead of JUnit?

1. The declaration of @BeforeClass and @AfterClass method has to be static in JUnit whereas, there is more flexibility in TestNG in the method declaration, it does not have these constraints.
2. In TestNG, we can parametrize tests using 2 ways. @Parameter or @DataProvider annotation.
   i) @Parameter for simple cases, where key value mapping is required.(data is provided through xml file)
   ii) @DataProvider for complex cases. Using 2 dimensional array, It can provide data.
3. In TestNG, since @DataProvider method need not be static, we can use multiple data provider methods in the same test class.
4. Dependency Testing: In TestNG, if the initial test fails, then all subsequent dependent tests will be skipped, not marked as failed. But JUnit marked it failed.
5. Grouping: Single tests can belong to multiple groups and then run in different contexts (like slow or fast tests). A similar feature exists in JUnit Categories but lacks the @BeforeGroups / @AfterGroups TestNG annotations that allow initializing the test / tearing it down.
6. Parallelism: If you’d like to run the same test in parallel on multiple threads, TestNG has you covered with a simple to use annotation while JUnit doesn’t offer a simple way to do so out of the box.
7. TestNG @DataProvider can also support XML for feeding in data, CSVs, or even plain text files.
8. TestNG allows you to declare dependencies between tests, and skip them if the dependency test didn’t pass.

@Test(dependsOnMethods = { "dependOnSomething" })

This functionality doesn’t exist in JUnit

9. Reporting:

TestNG reports are generated by default to a test-output folder that includes HTML reports with all of the test data, passed/failed/skipped, how long did they run, which input was used and the complete test logs. In addition, it also exports everything to an XML file which can be used to construct your own report template.

On the JUnit front, all of this data is also available via XML, but there’s no out of the box report and you need to rely on plugins.

Resource Link:

1. A Quick JUnit vs TestNG Comparison
2. JUnit vs. TestNG: Which Testing Framework Should You Choose?

A good difference is given in this tutorial side by side: TestNG Vs JUnit: What's the Difference?

How to get a current class name and methods that executed in the class file using TestNG listeners?

Answer:

Use ITestResult, ITestContext and IMethodInstance which can give you class name and method name which are using.

for (ITestResult testResult : testResultSet) {
    String methodName = testResult.getName() + "(";
    for (Object arg : testResult.getParameters()) {
        methodName += arg == null ? "" : arg.toString() + ", ";
    }

    uniqueMethodMap.add(testResult.getName());
    methodList.add(testResult.getParameters().length > 0 ?    methodName.substring(0, methodName.length() - 2) + ")" : methodName + ")");
}




Orignal Link: How to get a current class name and methods that executed in the class file using TestNG listeners?

Java - TestNG : Why Assertion always passes when written within try-catch block?

If you go through the source code of junit4, https://github.com/junit-team/junit4/blob/master/src/main/java/junit/framework/Assert.java#L71

You will get why the test1 is failing

Part#1:

/**
 * Asserts that two objects are equal. If they are not
 * an AssertionFailedError is thrown with the given message.
 */

static public void assertEquals(String message, Object expected, Object actual) {
    if (expected == null && actual == null) {
        return;
    }
    if (expected != null && expected.equals(actual)) {
        return;
    }
    failNotEquals(message, expected, actual); //It calls Part#2
}

Part#2:

static public void failNotEquals(String message, Object expected, Object actual) {
    fail(format(message, expected, actual)); //It calls Part#3 format(...) method
}

Part#3:

public static String format(String message, Object expected, Object actual) {
    String formatted = "";
    if (message != null && message.length() > 0) {
        formatted = message + " ";
    }
    return formatted + "expected:<" + expected + "> but was:<" + actual + ">";
}

So you have gotten Part#3's return message as

java.lang.AssertionError: expected [20] but found [12]

For full phase understanding of Exceptions JUnit Rule, Go through the following tutorial:

Expecting Exceptions JUnit Rule

To make an assertion that an exception was thrown with JUnit, it’s fairly common to use the try/fail/catch idiom or the expected element of the @Test annotation. Despite being more concise than the former, there is an argument that using expected doesn’t support all the cases you may want to test. The example being to perform additional testing after the exception or testing against the actual exception message.

JUnit 4.7 introduces the next progression, a @Rule that offers the best of both worlds. This articles weighs up the pros and cons of each approach and takes a closer look at the syntax of each. The try/fail/catch Idiom

The typical pattern is to catch an exception or fail explicitly if it was never thrown.

@Test
public void example1() {
    try {
        find("something");
        fail();
    } catch (NotFoundException e) {
        assertThat(e.getMessage(), containsString("could not find something"));
    }
    // ... could have more assertions here
}

which would highlight a failure in the following way.

java.lang.AssertionError: expected an exception
    at org.junit.Assert.fail(Assert.java:91)
    at bad.roboot.example.ExceptionTest.example1(ExceptionTest.java:20)
    ...

The idiom has potential advantages in that it offers the opportunity to assert against the actual exception as well as performing additional work after the expectation. Aside from the noise, the major drawback however is that its very easy to forget to include the fail call. If genuinely doing test first, where we always run the test red, this wouldn’t be a problem but all too often things slip through the net. In practice, I’ve seen far too many examples with a missing fail giving false positives.

@Test (expected = Exception.class)

Using the expected element, we can rewrite the test as follows.

@Test (expected = NotFoundException.class)
public void example2() throws NotFoundException {
    find("something");
    // ... this line will never be reached when the test is passing
}

which will result in the following failure.

java.lang.AssertionError: Expected exception: bad.robot.example.NotFoundException

Resource Link: What exactly does assertEquals check for when asserting lists?

Resource Link: https://stackoverflow.com/a/43768842/2293534