How to use setGenerateGroupsAttribute method of org.testng.reporters.XMLReporterConfig class

There is no way to force testng to do that. A solution is to set webdriver instance to a threadlocal variable. What this would help doing is, it would create one webdriver object per thread, if u do a get on the variable, it. Would give u that thread's object only.

Okay, I tried to convert my example to TestNG and it worked for me after following the example at https://code.google.com/p/powermock/wiki/TestNG_usage.

I get the MissingMethodInvocationException you mentioned when I'm omitting the required test class annotation @PrepareForTest(AbstractAnimal.class).

I'm using eclipse 4.4.1 with the TestNG plugin version 6.8.6.

See below for my converted example and the dependencies. Also, notice the extension of PowerMockTestCase. I did not change the sample class AbstractAnimal.

import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.testng.PowerMockTestCase;
import org.testng.Assert;
import org.testng.annotations.Test;

@PrepareForTest(AbstractAnimal.class)
public class AbstractAnimalTest extends PowerMockTestCase {

    @Test
    public void shouldGetMockedHello() {
        PowerMockito.mockStatic(AbstractAnimal.class);
        PowerMockito.when(AbstractAnimal.getHello()).thenReturn("Hello mocked animal world!");

        String greetings = AbstractAnimal.getHello();
        Assert.assertTrue(greetings.equals("Hello mocked animal world!"));
    }

}

Dependendencies (I tried to use your versions):

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.gnollix.stackoverflow</groupId>
    <artifactId>mock-static-abstract</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>6.8.8</version>
        </dependency>
        <dependency>
            <groupId>org.powermock</groupId>
            <artifactId>powermock-module-testng</artifactId>
            <version>1.5.6</version>
        </dependency>
        <dependency>
            <groupId>org.powermock</groupId>
            <artifactId>powermock-api-mockito</artifactId>
            <version>1.5.6</version>
        </dependency>
    </dependencies>

</project>

Resolved dependencies:

Hope that's useful!

Your problem is you never check the value from the Future to see if the exception was thrown.

This will correctly fail the test:

@Test
public void parallelTestWillFail() throws InterruptedException, ExecutionException {
    ExecutorService executor = Executors.newFixedThreadPool(10);
    Runnable testcaseNotOk = () -> fail("This failure IS raised.");
    List<Future<?>> futures = IntStream.range(0, 20)
                                .mapToObj(i -> executor.submit(testcaseNotOk))
                                .collect(Collectors.toList());
    executor.shutdown();
    for(Future<?> f : futures){
        f.get();
    }
}

How to see the real benefits of the approach described in the book?

The purpose of separate instance is not for any benefit but to maintain the contract that each test should be independently executed without any effect of the execution of a previous test. There is just no other way to ensure this contract other than using a different instance for each test.

For example, the Spring transaction management makes sure to rollback all changes made to the database by a test, by default, to maintain the same contract.

So, using static variables in a test is generally discouraged as it will defeat the whole purpose of one-instance-per-test to have a clean slate for each test.

Spring Data JPA by default looks for an EntityManagerFactory named entityManagerFactory. Check out this part of the Javadoc of EnableJpaRepositories or Table 2.1 of the Spring Data JPA documentation.

That means that you either have to rename your emf bean to entityManagerFactory or change your Spring configuration to:

<jpa:repositories base-package="your.package" entity-manager-factory-ref="emf" /> 

(if you are using XML)

or

@EnableJpaRepositories(basePackages="your.package", entityManagerFactoryRef="emf")

(if you are using Java Config)

Try this:

gradle :clean  -Dtest.single=Name_of_your_test_here test

YOu do not have to pass the driver around or call on testfailure within the test (infact this defeats the point of test listeners);

The following will achieve screenshots in listeners without passing the driver around;

1. All test classes must extend a simple base test class;

   public asbtract baseTestCase() {
   
       private WebDriver driver;
   
       public WebDriver getDriver() {
               return driver;
   }
   
       @BeforeMethod
       public void createDriver() {
               Webdriver driver=XXXXDriver();
       }
   
       @AfterMethod
           public void tearDownDriver() {
           if (driver != null)
           {
                   try
                   {
                       driver.quit();
                   }
                   catch (WebDriverException e) {
                       System.out.println("***** CAUGHT EXCEPTION IN DRIVER TEARDOWN *****");
                       System.out.println(e);
                   }
   
           }
       }
   

2. In your listener, you need to access the base class;

public class ScreenshotListener extends TestListenerAdapter {

@Override
public void onTestFailure(ITestResult result)
{
        Object currentClass = result.getInstance();
        WebDriver webDriver = ((BaseTest) currentClass).getDriver();

        if (webDriver != null)
        {

           File f = ((TakesScreenshot) webDriver).getScreenshotAs(OutputType.FILE);

           //etc.
        }
}

Your test is now unaware that a screenshgot is even being captured and can be controlled by the adding of the listener.

I am using QAF for Test Automation, its inbuilt reporter generates time required for each step to execute and displays in report. I found QAF is the easiest way for detailed reporting.

with QAF your code can look like as below

@Test(priority = 1, description = "Login to Oasis")
public void verifyFilter(){
//Step#1
    CommonStep.startTransaction("Step#1: name of the step");

    navMenu = loginToApplication(username, password);
    Assert.assertTrue(navMenu.isDisplayed(getWebDriverInstance()), "Login Failed!!!");

    CommonStep.stopTransaction();

    //Step#2
    CommonStep.startTransaction("Step#2: name of the step");

    advancedSearchForm = navMenu.clickSearchAllTitles();
    if (!advancedSearchForm.isDisplayed(getWebDriverInstance())) {
        SimpleSearchFormElement simpleSearchForm = new SimpleSearchFormElement(getWebDriverInstance());
        advancedSearchForm = simpleSearchForm.openAdvancedSearchForm();
    }
    Assert.assertTrue(advancedSearchForm.isDisplayed(getWebDriverInstance()), "Advanced Search Form is not displayed!");
        CommonStep.stopTransaction();

//Step#3
    CommonStep.startTransaction("Step#3: name of the step");

    collectionFilterDialog = advancedSearchForm.openCollectionFilterDialog();
    boolean flag = collectionFilterDialog.isCollectionSelectableListDisplayed();
    Assert.assertTrue(flag, "Collection Filer dialog is not displayed!");

    CommonStep.stopTransaction();

}

above way is on the fly step declaration. Another way to define step:

@QAFTestStep(description="login using {user} and {password}")
public void login(String userName, String pwd) {
    //your code here
}

Call this method in testNG test, you will find step in report. Another benefit of teststep is you can call this step in bdd also using description.

There's not a lot of context in that question but a quick google found the source.

Your test suite will create many instances of different classes and then run some tests on them. This particular parallel mode guarantees that whenever your test suite calls more than one method on any create instance this will be done in the same thread.

Why might this be important? Well, some functionality may depend on consistent threading, for example if they use ThreadLocal. Additionally, unless your instances are thread-safe allowing multiple threads to call methods on them could lead to interference.

If you're not sure what all this talk of thread safety is then you might not want to run your test suite in parallel. Or perhaps restrict it to parallel="tests" and make sure there's a clear separation between test tags.