How to use XmlGroups class of org.testng.xml package

I've needed this several times as well. I've put together a small sample below, which you'd want to adjust to your needs. Basically, you create your own Appender and add it to the logger you want. If you'd want to collect everything, the root logger is a good place to start, but you can use a more specific if you'd like. Don't forget to remove the Appender when you're done, otherwise you might create a memory leak. Below I've done it within the test, but setUp or @Before and tearDown or @After might be better places, depending on your needs.

Also, the implementation below collects everything in a List in memory. If you're logging a lot you might consider adding a filter to drop boring entries, or to write the log to a temporary file on disk (Hint: LoggingEvent is Serializable, so you should be able to just serialize the event objects, if your log message is.)

import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MyTest {
    @Test
    public void test() {
        final TestAppender appender = new TestAppender();
        final Logger logger = Logger.getRootLogger();
        logger.addAppender(appender);
        try {
            Logger.getLogger(MyTest.class).info("Test");
        }
        finally {
            logger.removeAppender(appender);
        }

        final List<LoggingEvent> log = appender.getLog();
        final LoggingEvent firstLogEntry = log.get(0);
        assertThat(firstLogEntry.getLevel(), is(Level.INFO));
        assertThat((String) firstLogEntry.getMessage(), is("Test"));
        assertThat(firstLogEntry.getLoggerName(), is("MyTest"));
    }
}

class TestAppender extends AppenderSkeleton {
    private final List<LoggingEvent> log = new ArrayList<LoggingEvent>();

    @Override
    public boolean requiresLayout() {
        return false;
    }

    @Override
    protected void append(final LoggingEvent loggingEvent) {
        log.add(loggingEvent);
    }

    @Override
    public void close() {
    }

    public List<LoggingEvent> getLog() {
        return new ArrayList<LoggingEvent>(log);
    }
}

} catch (Exception e) {
  System.out.println("Unable to wait and click on element, Exception: " + e.getMessage());
}

You are catching all exceptions, so the test won't fail.

Try extending XmlTest in your test class and call setName(). I extended XmlSuite and used setName to name my "test suite" which is a class with multiple tests defined in it and that worked for me. In fact I just tried what I suggested on the same class and now it's called a test with the correct name. I'm not sure why the ITest interface is being ignored as I also tried that approach without success.

No, but nothing stops you from merging these two data providers into one and specifying that one as your data provider:

public Object[][] dp1() {
  return new Object[][] {
      new Object[] { "a", "b" },
      new Object[] { "c", "d" },
  };
}

public Object[][] dp2() {
  return new Object[][] {
      new Object[] { "e", "f" },
      new Object[] { "g", "h" },
  };
}

@DataProvider
public Object[][] dp() {
  List<Object[]> result = Lists.newArrayList();
  result.addAll(Arrays.asList(dp1()));
  result.addAll(Arrays.asList(dp2()));
  return result.toArray(new Object[result.size()][]);
}

@Test(dataProvider = "dp")
public void f(String a, String b) {
  System.out.println("f " + a + " " + b);
}

You need to use dataproviderthreadcount. The threadpoolsize and invocationcount values are not required. See details here.

In my project when I set reuseForks=true then i have to increase the forkCount to number of test classes. Otherwise, It is throwing illegalargument exception.

From the stack trace, it appears something inside your code is causing the exception to be thrown, but only when forks are reused. This implies that the different tests are somehow not isolated from each other, and therefore running one after the other within the same test process violates some assumptions. For example, perhaps one test initializes some global state like a singleton, and then that global state isn't correct for the next test run within that process.

Also, If I set reuseForks=false then it also work fine.

By setting reuseForks to false, any problems related to mutating global state like this get bypassed. The process gets torn down at the end of the test run, and a new process with fresh state gets started for the next test run.

At this point, the path forward is highly dependent on the specifics of your codebase and how its tests are implemented. I see 2 options:

1. Debug your tests looking for problems of global state like I described. Attaching a breakpoint right before this exception would probably give you a strong hint.
2. If you already know that the codebase relies on some global state, and it isn't feasible to change that code quickly, then just stick with reuseForks set to false. In many cases, the extra process teardown and startup won't cause a noticeable performance impact for your overall test run.

As your tests got skipped, you may want to check test results xml first to find out the root cause (exception).

On the other hand, I'm just wondering what's the initial intention of using a library, which is not maintained for 4 years? ReportNG is dead. It's a fact. And if you take a look at its sources, you'll see which TestNG version it uses (6.8). You could easily assume that its reporter is based on old TestNG API.

When you add TestNG 6.11 as a dependency, the probability of a jar hell occurrence is quite high. And I wouldn't be surprised, if it's a root cause of your issue.

If you haven't decided which reporting system to use yet, I'd recommend to take a look at a modern Allure 2 framework.

Otherwise, just check a stacktrace first to understand the root cause of your issue.

Peter Niederwieser is right.

In addition you can set the order of the tests to run within the classes (Junit 4.11):

import org.junit.runners.MethodSorters;

import org.junit.FixMethodOrder;
import org.junit.Test;
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {

    @Test
    public void firstTest() {
        System.out.println("first");
    }

    @Test
    public void secondTest() {
        System.out.println("second");
    }
}

I have also implemented the same extending Testng TestListenerAdapter. By capturing the screenshot then attach it to the Testng Report with the image of size height=100 and width=100 with onTestFailure. Please see below if this helps solve your problem

    File scrFile = ((TakesScreenshot) WebdriverManager.globalDriverInstance).getScreenshotAs(OutputType.FILE);
      //Needs Commons IO library
      try {
        FileUtils.copyFile(scrFile, new File(file.getAbsolutePath()+ "/selenium-reports/html/" + result.getName() + ".jpg"));
        Reporter.log("<a href='"+ file.getAbsolutePath()+"/selenium-reports/html/" + result.getName() + ".jpg'> <img src='"+ file.getAbsolutePath()+"/selenium-reports/html/"+ result.getName() + ".jpg' height='100' width='100'/> </a>");
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
    Reporter.setCurrentTestResult(null);