How to use setInterceptedPriority method of org.testng.Interface ITestNGMethod class

From TestNG Documentation 5.10.2 - Parallel tests, classes and methods:

The parallel attribute on the tag can take one of following values:

<suite name="My suite" parallel="methods" thread-count="5">

<suite name="My suite" parallel="tests" thread-count="5">

<suite name="My suite" parallel="classes" thread-count="5">

<suite name="My suite" parallel="instances" thread-count="5">

• parallel="methods": TestNG will run all your test methods in separate threads. Dependent methods will also run in separate threads but they will respect the order that you specified.

• parallel="tests": TestNG will run all the methods in the same tag in the same thread, but each tag will be in a separate thread. This allows you to group all your classes that are not thread safe in the same and guarantee they will all run in the same thread while taking advantage of TestNG using as many threads as possible to run your tests.

• parallel="classes": TestNG will run all the methods in the same class in the same thread, but each class will be run in a separate thread.

• parallel="instances": TestNG will run all the methods in the same instance in the same thread, but two methods on two different instances will be running in different threads.

As such, if by "thread safe" you mean there won't be more than one TestNG thread interacting with any given test class instance then yes, using "classes" will get you what you want. However, "tests" does not run each test method in its own thread but each <test> tag from you testng.xml. The descriptions above should help.

I recommend to use approach from article: https://github.com/mockito/mockito/wiki/Mocking-Object-Creation

You need to change little bit a class, applying approach for mocking from article in following way:

AwsHelper

public class AwsHelper {

    private AmazonSQS sqs;

    public void sendMessageToQueue(String message) {
        sqs = defaultClient();

        SendMessageRequest sendMessageRequest = new SendMessageRequest();
        sendMessageRequest.setQueueUrl("");
        sendMessageRequest.setMessageBody(message);
        sendMessageRequest.setMessageGroupId("");

        sqs.sendMessage(sendMessageRequest);
    }

    protected AmazonSQS defaultClient() {
        return AmazonSQSClientBuilder.defaultClient();
    }
}

AwsSQSReferralsUtilTest

public class AwsSQSReferralsUtilTest {

    @Spy
    private AwsHelper awsHelper;

    @Mock
    private AmazonSQS sqs;

    @BeforeClass
    public void setUp() {
        MockitoAnnotations.initMocks(this);
    }
    
    @AfterMethod
    public void afterEachMethod() {
        Mockito.reset(awsHelper);
    }

    @Test
    public void shouldSendMessage() {
        //mocking object creation
        doReturn(sqs).when(awsHelper).defaultClient();

        when(sqs.sendMessage(any(SendMessageRequest.class))).thenReturn(new SendMessageRequest());
        awsHelper.sendMessageToQueue("");
    }

}

} 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.

You are doing it right, but we will have to wait when mocking static interface method is implemented/fixed in PowerMock. Watch this pull request: https://github.com/jayway/powermock/issues/510

Note: Good news is that issue in Javassist is already fixed:

https://github.com/jboss-javassist/javassist/pull/11

Spawn a child JVM process using ProcessBuilder or Runtime and you will be able to terminate that process when the user requests that the script stops running.

If you have same type of parameters then you can pass as a array in method parameter.

@Test (dataProvider = "Dataprovider1")
public void testScenario1(String args [])
            ) throws Exception {
    System.out.println(args[0]+"---------------- "+args[1]+" ---------------   "+args[3]+" .. so on");
}

Also if you have different type of parameter field then you can beak it with help of a helper class and then pass the reference of this class in parameter. e.g:

class Helper {
  String data1;
  String data2;
  String data3;
  Long data4;
  int data5;
  flot data6;
 -----so on------
 ----getter setter and constructor----
}

your test class

class Test {
@DataProvider(name="Dataprovider1")
public static Object[][] testData() {
    return new Object[][] {
            { new Helper("hey", "you", "guys" ..... another constructor parameters..) } }
    };

}

@Test (dataProvider = "Dataprovider1")
public void testScenario1(Helper helper) throws Exception {
    System.out.println(helper.data1+"---------------- "+helper.data2+" ---------------   "+helper.data3+" .. so on");
}
}

From version 4.11 you can specify execution order using annotations and ordering by method name:

import org.junit.Test;
import org.junit.FixMethodOrder;
import org.junit.runners.MethodSorters;

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class MyTest {

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

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

See JUnit 4.11 Release Notes

In my Selenium IDE version 2.4.0 it is easy as pie:

1. Record testcase in Selenium IDE
2. Click File - Export Test Case As - Java / JUnit4 / WebDriver
3. Save File as .java

And here you go! Your testcase is converted to WebDriver ;)

How can I make sure I do not lose results of the tests that did run successfully(though passed/failed)?

There are usually two ways in which you can build reporting into your TestNG driven tests.

1. Batched mode - This is usually how all the TestNG reports are built. A listener which implements org.testng.IReporter interface is built and within its generateReport(), all the logic of consolidating the test results into a report is carried out.
2. Realtime mode - This is usually done by implementing the TestNG listener org.testng.IInvokedMethodListener and then within its afterInvocation() do the following :
   • Check the type of the incoming org.testng.IInvokedMethod (to see if its a configuration method (or) a @Test method ) and handle these types of methods differently (if the report needs to show them separately). Then test the status of org.testng.ITestResult and based on the status, show them as PASS/FAIL/SKIPPED

IReporter implementations are run at the end after all the tests have run (which is why i call them as batched mode). So if something crashes towards the end but before the reporting phase is executed, you lose all execution data.

So you might want to try and build a realtime reporting model. You can take a look at the RuntimeReporter report that SeLion uses. Its built on the realtime model.

Is a test management tool or some entity to store the run time results , a mandatory requirement or TestNG has some provision built-in?

There are no such mandatory requirements that TestNG places. As I explained above, it all boils down to how you are constructing your reports. If you are constructing the reports in a realtime fashion (you can leverage templating engines such as Velocity/Freemarker/Thymeleaf) to build your reporting template and then use the IInvokedMethodListener to inject values into the template, so that it can be rendered easily.

Read more here for a comparison on the templating engines so that you can choose what fits your need.