How to use getMissMatchedTestNames method of org.testng.xml.internal.TestNamesMatcher class

There are lots of problems here.

First, I count three citations of the JNDI lookup string in your small example. DRY would tell you to write it once and refer to it, if possible.

Second, I don't appreciate your DAO very much. Is this really what you're writing, or is this just an example? I don't think this is the Spring idiom. There's no interface. How will you do declarative transactions without one? I'd recommend looking at the Spring docs for iBatis more carefully.

Third, I'd recommend using JUnit 4.4 or, better yet, the TestNG idiom - annotations. Also check out the Spring @ContextConfiguration to inject the beans you need in setUp.

Fourth, your DAOs cannot work because you need a JNDI lookup service running, and you can't get one without the container. The answer is to have a DriverManager data source for your tests.

UPDATE: Here's an idea to try: Use the Spring idiom for iBatis. If legacy prevents you from doing this, perhaps Spring isn't your answer.

Once you do this, all you have to do is override the data source app context to use DriverManager instead of JNDI for your test.

What you will want to do is create a rule for handling test results. This rule will be created as a TestWatcher, then you will override its failed and succeeded methods. Example:

@Rule
public TestWatcher watchman = new TestWatcher() {
    @Override
    protected void failed(Throwable e, Description description) {
        // Handle logging of failing tests
        System.out.println("Fail!");
    }

    @Override
    protected void succeeded(Description description) {
        // Handle logging of succeeding tests
       System.out.println("Success!");
    }
};

The description parameter contains information about the failing class http://junit.sourceforge.net/javadoc/org/junit/runner/Description.html

As for the method annotations, the following annotations are the TestNG - JUnit 4 equivalents:

@BeforeTest - @BeforeClass

@AfterTest - @AfterClass

@BeforeMethod - @Before

@AfterMethod - @After

The following code demonstrates how you could structure your test class:

public class MyTestClass {
    @Rule
    public TestWatcher watchman = new TestWatcher() {
        @Override
        protected void failed(Throwable e, Description description) {
            // Handle logging of failing tests
            System.out.println("Fail!");
        }

        @Override
        protected void succeeded(Description description) {
            // Handle logging of succeeding tests
            System.out.println("Success!");
        }
    };

    @BeforeClass
    public static void setup() {
        //Some setup before all test methods
    }

    @AfterClass
    public static void cleanup() {
        // Some cleanup after all test methods
    }

    @Before
    public void register() {
        // Some setup before each test method
    }

    @Test
    public void succeedingTest() {
        Assert.assertTrue(true);
    }

    @Test
    public void failingTest() {
        Assert.assertTrue(false);
    }
}

It seems below jar is not available in your classpath. com.google.guava_1.6.0.jar

Download from the link below and add it to your classpath.

com.google.guava_1.6.0.jar

The main challenge of record&replay systems that reproduce concurrency bugs is the large amount of information that needs to be recorded. To record the thread interleaving of shared variables generates very big logs and big slowdowns. Therefore, the most recent research works attempt to perform partial logging and then use SMT solvers to complete the missing (not recorded) parts of the interleavings.

To the extent of my knowledge, the most recent advance in this area is a system called Symbiosis. Open source implementations for java/c/c++ are available (as well as tests, examples and the published paper) in this URL:

http://www.gsd.inesc-id.pt/~nmachado/software/Symbiosis_Tutorial.html

Hope it helps. Sorry for the late reply, but I joined recently

Java comes with Java DB.

That said, I would advise against using a different type of DB than what you use in production unless you go through an ORM layer. Otherwise, your SQL might not be as cross-platform as you think.

Also check out DbUnit

Because you defined dependsOnMethods for TestCaseSecond and TestCaseThird. It takes priority over priority attribute. From testng Dependencies with annotations

All the methods you depend on must have run and succeeded for you to run

TestCaseFourth has the highest priority (3) without dependency -> it runs first.

TestCaseOne() has the next highest priority (4) without dependency -> it runs second

TestCaseSecond() has the highest priority with all dependencies met (TestCaseOne ran) -> it runs third

TestCaseThird() has the highest priority with all dependencies met (TestCaseSecond ran) -> it runs fourth

Using the JMockit Expectations API, a test can verify constructor invocations just like method invocations. The test just needs to specify the class as @Mocked. For example:

@Test
public void exampleTestThatVerifiesConstructorCall(@Mocked FileInputStream anyFIS)
{
    new MyClass().doSomething();

    new Verifications() {{ new FileInputStream("someFile.txt"); }};
}

That said, I would recommend to avoid mocking low-level classes like FileInputStream, which usually are just internal implementation details of the class under test. A better test would use an actual file and check somehow that it was read as expected.

This is related to extent report. I'm not sure how you write your @after method but only what i can guess is you use reports.endTest(test); in your code. This is in older version of extent report. Most probably your problem is with it. Here is an alternative with latest extent report solution since no extent report related code for your problem is available in here.

@AfterMethod
public synchronized void afterMethod(ITestResult result) {

    StringBuilder inputArgs = new StringBuilder();
    Object objects[] = result.getParameters();

    for(Object obj : objects){
        if(obj==null){
            inputArgs.append("  ");
        }else{
            inputArgs.append(obj.toString());
        }
        inputArgs.append(" , ");
    }

    if (result.getStatus() == ITestResult.FAILURE)
        test.get().fail(result.getThrowable()+ "Input Parameters : "+inputArgs.toString());
    else if (result.getStatus() == ITestResult.SKIP)
        test.get().skip(result.getThrowable() + "Input Parameters : "+inputArgs.toString());
    else
        test.get().pass( " Test Passed. Input parameters : " +inputArgs.toString());
    extent.flush();
}

My preferred way to test code that uses Hibernate is to use @BeforeMethod and @AfterMethod test approach. I don't have any experience with TestNg, but I assume the way it treats those functions is similar to what JUnit3.8.1 does with setUp() and tearDown(), which is what I use.

The key point to me is the idea that the order of unit test execution shouldn't matter. If you're using @BeforeGroup and @AfterGroup, then you have the same SessionFactory instance, and therefore the same database (in memory or not), and any mutating operations that a test runs on that SessionFactory will affect later tests that do read operations. That may be desired (although the order probably has to be predictable), in which case you're really talking about a single 'integration test', but for your case it sounds like you want the tests to be independent.

Next question is how to do that. What I do is configure Hibernate to create and connect to in-memory database, run the create schema script on it, and create a SessionFactory, for each test method.

@Override
protected void setUp() throws Exception {
    super.setUp();
    String dialectClassName = HSQLDialect.class.getName();
    AnnotationConfiguration config = new AnnotationConfiguration().addAnnotatedClass(DividendScheduleGeneratorImpl.class);

    config.setProperty(Environment.DIALECT, dialectClassName);
    config.setProperty(Environment.DRIVER, jdbcDriver.class.getName());
    config.setProperty(Environment.URL, "jdbc:hsqldb:mem:testDB");
    config.setProperty(Environment.USER, "SA");
    config.setProperty(Environment.PASS, "");

    SchemaExport export = new SchemaExport(config);
    export.create(false, true);

    sessions = config.buildSessionFactory();
}

@Override
protected void tearDown() throws Exception {
    sessions.close();
    sessions = null;

    super.tearDown();
}

Couple of notes:

1. The schema creation is not all that fast, at least with HSQLDB, which I use. But as long as you cleanly separate tests that are really testing Hibernate, from tests which use a mockable persistence layer, you should be fine because there won't be that many tests having to work with an actual database.
2. My tests are run single-threaded. If you're running multi-threaded, you'll need to set the database name so that it's unique for concurrently running tests.

EDIT:

Based on your error stack trace and code, and the fact the tests run independently, I suspect the PessimisticLockExceptions are being caused by the tests running on separate threads against the same database. Possibly you even have a database-centered deadlock on the RATES table. Two options for dealing with it are having the tests generate independent databases, or to tell TestNG to run the tests serially.

For the first, you would have to programatically edit the Hibernate connection string from

jdbc:h2:mem:db1;DB_CLOSE_DELAY=0;MVCC=true

to

jdbc:h2:mem:<TESTNAME>;DB_CLOSE_DELAY=0;MVCC=true

or similar. In JUnit, I'd use the TestCase.getName(), I assume there is a similarly available feature in TestNG.

The alternative is to run serially. According to the TestNG documentation, serializing the tests should be possible by annotating the class (not the methods) to add @Test(singleThreaded=true)

@Test(singleThreaded=true)
public class RatesPersistanceTest

That's how it's supposed to work at least, perhaps when you tried it you annotated the method?