2

I'm getting a string value from a function. Now I want to print a message saying whether expected string and actual string are different or not.

To compare these string I'm using TestNG's Assert.assertEquals method.

If strings are equal print --> Equal
Else print ---> not equal

  • I assume you’re using Java? But why do you want to print the results manually? Your IDE/build tool should give you the feedback you need, that is, which tests have passed and which have failed. – beatngu13 Apr 2 '18 at 8:58
  • Yeah it gives. But I want to print these output into a document in a simple way – Joe Apr 2 '18 at 9:01
  • I think, if I use try-catch I might be able to do it. But I'm looking for a better way if there is any – Joe Apr 2 '18 at 9:02
  • Try-catch would work, but that’s cumbersome. Are you using JUnit (4/5?)? – beatngu13 Apr 2 '18 at 9:12
  • Im using testNG – Joe Apr 2 '18 at 9:17
5

The easiest way is to wrap the assertion within a try-catch block, something like:

try {
    Assert.assertEquals(actualString, expectedString);
} catch (AssertionError e) {
    System.out.println("Not equal");
    throw e;
}
System.out.println("Equal");

A more sophisticated solution would be to use TestNG's extension mechanism for logging:

It's very easy to generate your own reports with TestNG with Listeners and Reporters:

  • Listeners implement the interface org.testng.ITestListener and are notified in real time of when a test starts, passes, fails, etc...
  • Reporters implement the interface org.testng.IReporter and are notified when all the suites have been run by TestNG. The IReporter instance receives a list of objects that describe the entire test run.

For example, if you want to generate a PDF report of your test run, you don't need to be notified in real time of the test run so you should probably use an IReporter. If you'd like to write a real-time reporting of your tests, such as a GUI with a progress bar or a text reporter displaying dots (".") as each test is invoked […], ITestListener is your best choice.

| improve this answer | |
  • Do listeners or reporters have information about all assertions that passed in a given test methods? – dzieciou May 4 '18 at 13:16
4

The best practice of TestNg behavior overriding is using so called listeners. For example you can override the dafault behavior of what is happenning when your assert fails. To do that you need to extend TestListenerAdapter class as it is shown below:

import org.testng.ITestResult;
import org.testng.TestListenerAdapter;

public class StringComparatorListener extends TestListenerAdapter {

    @Override
    public void onTestFailure(ITestResult iTestResult) {
        System.out.println("Not Equal");
        super.onTestFailure(iTestResult);
    }

    @Override
    public void onTestSuccess(ITestResult iTestResult) {
        System.out.println("Equal");
        super.onTestSuccess(iTestResult);
    }
}

Now you should add the listener to your test. Either by configuring testng.xml or by adding listener straigt in the code. Below is the example of how to add the above listener to your code:

import org.testng.annotations.Listeners;
import org.testng.annotations.Test;
import static org.testng.Assert.assertEquals;


@Listeners(test.StringComparatorListener.class)
public class TestChangeTestNgBehavior {

    @Test
    public void testAdd() {
        String str = "One string";
        assertEquals("Other string", str);
    }

}

This is the minimal and complete example which you can run and test and amend according to your particular need.

| improve this answer | |
0

Another solution is to decorate org.testng.Assert with logging feature:

public class MyAssert {

   public static void assertEquals(String actualString, String expectedString) {
     try {
       org.testng.Assert.assertEquals(actualString, expectedString);
       log.trace("Equal");
     } catch (AssertionError e) {
       log.trace("Not equal");
       throw e;
     }
   }
} 

You can decorate other assertion methods like assertTrue, assertThat, etc. in a similar way. Yes, the logic is the same to what others have proposed, but the difference is that you don't repeat same logging/printing logic in every test. That specifically makes sense when a test method contains multiple assertions (soft assertions in particular).

PS. Note, usage of assertEquals is discouraged in favour to assertThat.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.