How to use toString method of org.testng.TestListenerAdapter class

You are sharing a single instance of the class under test across all tests. I'd remove the initial assignment and add this:

private GameOfStones gameOfStones; // Don't create an instance here

@BeforeMethod
public void setUp() {
    gameOfStones = new GameOfStones();
}

... which will use a new instance for each test. Good practice would also be to clean up after each test:

@AfterMethod
public void tearDown() {
    gameOfStones = null;
}

In the example given here, fixing the class scoped variable causing the problem to be method scoped instead would also fix the issue, but as the software under test gets more complex it's good to start doing proper test set up and tear down.

There is no such a good idea to have following scenario :

for (WebElement element : webDriver.findElements(locator.getBy())){
  element.click();
}

Why? Because there is no guarantee that the element.click(); will have no effect on other found elements, so the DOM may be changed, so hence the StaleElementReferenceException.

It is better to use the following scenario :

int numberOfElementsFound = getNumberOfElementsFound(locator);
for (int pos = 0; pos < numberOfElementsFound; pos++) {
  getElementWithIndex(locator, pos).click();
}

This is better because you will always take the WebElement refreshed, even the previous click had some effects on it.

EDIT : Example added

  public int getNumberOfElementsFound(By by) {
    return webDriver.findElements(by).size();
  }

  public WebElement getElementWithIndex(By by, int pos) {
    return webDriver.findElements(by).get(pos);
  }

Hope to be enough.

An easier option is to use the @BeforeMethod annotation on a method which checks your condition. If you want to skip the tests, then just throw a SkipException. Like this:

@BeforeMethod
protected void checkEnvironment() {
  if (!resourceAvailable) {
    throw new SkipException("Skipping tests because resource was not available.");
  }
}

All independent methods (that do not have @dependsOnMethods dependency) will be executed first. Then methods with dependency will be executed. If there is ambiguity in execution order even after this ordering, priority comes into picture.

This is the ordering scheme:

1. Execute all independent methods (methods without @dependsOnMethods annotation)
2. If there is ambiguity in this ordering use priority to resolve ambiguity for independent methods
3. Execute dependent methods in order of dependency
4. If there is ambiguity in this ordering use priority to resolve ambiguity for dependent methods
5. If there is still ambiguity (due to not using priority or two methods having same priority) order them based on alphabetical order.

Now all ambiguity is resolved since no two methods can have the same name.

You can try exploring Factory for your needs. Factory would allow you to run all methods annotated with @Test of a class with different data. You can initalize ur webdriver in ur beforeclass in that case. Explanation here.

Each e-mail client chooses how it renders HTML e-mails. Several web-based clients need to strip out CSS so you don't hijack the look of the site. There is a minimal set of CSS selectors and HTML tags that each e-mail client chooses to allow. You probably need to make some major modifications to the emailable-report.html template so that it behaves for Gmail.

There are entire businesses built on their skills of creating cross-client e-mail templates; it might take you quite a bit of time and research to make one that works for Gmail (as well as all the other major clients).

Here are a few resources to get you started:

• http://www.campaignmonitor.com/css/
• http://www.campaignmonitor.com/resources/category-archive/cat/designing-and-building-emails/
• http://www.sitepoint.com/code-html-email-newsletters/
• Testing HTML email rendering

And a million others if you poke around on Google some more.

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.

Im not a java pro but i searched for your question i find some usefull links Link 1 Link 2 link 3

You can use the @Ignore annotation:

@Deprecated
@Test
@Ignore
public void comprovarEqualsIncorrecteNul()

Junit will tell you that it has skipped a test:

Tests run: 1, Failures: 0, Errors: 0, Skipped: 1

You can also add a comment in the tag for documentation:

@Ignore("Ignoring deprecated test.")

More generally, you can use a @Rule to conditionally skip deprecated test methods in a class:

public class SkipDeprecated implements TestRule {

    @Override
    public Statement apply(final Statement stmnt, final Description d) {
        if (d.getAnnotation(Deprecated.class) == null) {
            return stmnt;
        }
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                // Return an empty Statement object for those tests 
                // that shouldn't run.
            }
        };
    }
}

If there isn't an @Deprecated annotation then we continue as before. If there is one we return an empty Statement which effectively skips the tests.

In you test class you need to declare the rule:

@Rule
public final SkipDeprecated sd = new SkipDeprecated();

Example taken from Mike Reedell and modified slightly.

As Mike points out this isn't perfect as the test is marked as passed. I did some more googling and came across this, it's very old but summarises the issues with skipping tests in rules quite nicely.

EDIT

After a bit of experimentation the following seems to work very well with JUnit 4.11

public class SkipDeprecated implements TestRule {

    @Override
    public Statement apply(final Statement stmnt, final Description d) {
        if (d.getAnnotation(Deprecated.class) == null) {
            return stmnt;
        }
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                throw new AssumptionViolatedException("Test is deprecated.");
            }
        };
    }
}

This leverages JUnit's Assume API and throws an AssumptionViolatedException from the Statement that is used for @Deprecated tests. This causes JUnit to think that the test is not applicable in these circumstances and report it as skipped - which is preferable to it being reported as passed as happens in the no-op case.