Announcement Announcement Module
No announcement yet.
junit.framework.AssertionFailedError: TestCase.getName() cannot be null Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • junit.framework.AssertionFailedError: TestCase.getName() cannot be null

    I am currently using AbstractJpaTests with TestNG. When I run my test, I get the following exception thrown in the setup() method.

    junit.framework.AssertionFailedError: TestCase.getName() cannot be null

    The stack trace is:

    junit.framework.AssertionFailedError: TestCase.getName() cannot be null
    at junit.framework.Assert.assertTrue(
    at junit.framework.Assert.assertNotNull( 17)
    at org.springframework.test.annotation.AbstractAnnota tionAwareTransactionalTests.getTestMethod(Abstract
    at org.springframework.test.annotation.AbstractAnnota tionAwareTransactionalTests.isRollback(AbstractAnn
    at org.springframework.test.AbstractTransactionalSpri ngContextTests.onSetUp(AbstractTransactionalSpring
    at org.springframework.test.AbstractSingleSpringConte xtTests.setUp(AbstractSingleSpringContextTests.jav a:103)
    at com.zcorum.esb.dao.impl.BaseDAOTest.launchSetup(Ba

    Any ideas on why this might happen?

    Here is the test class:

    import org.testng.annotations.Test;

    import com.zcorum.esb.dao.ModemDAO;
    import com.zcorum.esb.models.modem.Modem;

    public class ModemDAOTest extends BaseDAOTest
    private ModemDAO modemDAO;

    public void setModemDAO(ModemDAO modemDAO)
    this.modemDAO = modemDAO;

    public void testGetModemByMacAddress()
    System.out.println("modemDAO: " + modemDAO);
    Modem modem = modemDAO.findByMacAddress("12:34:56:78:90:12");
    assertEquals("12:34:56:78:90:12", modem.getMacAddress());
    assertEquals("", modem.getIpAddress());
    assertEquals(new Long(1), modem.getId());
    assertEquals("", modem.getCmts().getIpAddress());

    public void testSaveModem()
    Modem modem = new Modem();
    modem.setSnmpGetPort(new Integer(161));
    modem.setSnmpVersion(new Integer(1));

    Modem secondModem = modemDAO.findById(new Long(1));


    assertEquals(new Long(2), modem.getId());

    public void testUpdateModem()
    Modem modem = modemDAO.findById(new Long(1));


    Modem updatedModem = modemDAO.update(modem);

    assertEquals("XD54", updatedModem.getModel());
    assertEquals("Motorolla", updatedModem.getVendor());
    assertEquals("", updatedModem.getIpAddress());


    @Test(dependsOnMethods = { "testGetModemByMacAddress", "testSaveModem" })
    public void testRemoveModem()
    Modem modem = modemDAO.findByMacAddress("21:443:65:87:09:21");

    modem = modemDAO.findByMacAddress("21:443:65:87:09:21");




  • #2
    I am facing same problem with my tests. Do you find solution for this?


    • #3
      If you include following method in your Class then it will work good.
      public String getName(){
      return "testGetModemByMacAddress";

      Some how it is bug in newer version of spring-test.jar ( which contain It is misising to set TestCase name.

      I found following things online.

      Spring 2.5's Support for TestNG

      Is in the toilet now. On my continuing desert odyssey to figure out how I can write a test that puts some info in the db before running the tests, then removes it, I ventured into 2.5, after finding this which I thought was a eureka moment as I finally found someone who was using JPA to do their setup (figures too it's Thomas Risberg). Problem is the AbstractJpaTests class is in the new spring-test jar in 2.5, and after pulling that in, I followed the Risberg example and overloaded onSetupInTransaction(), but that never gets called. After downloading the source, my suspicions were confirmed: there is no annotation to trigger the call to setup. Little further investigation revealed that there is now a testng package, but of course, the JPA tests don't extend those classes (and apparently, they have changed their TestNG strategy to use BeforeGroup/AfterGroup). Meanwhile, Spring now offers a bunch of test functionality that overlaps TestNG, e.g. @ExpectedExcption (though their's takes one class). It seems that the thinking in the Spring camp was that the AbstractTransactionalDataSourceTest was the last word on needing to provide db setup services. There are a plethora of examples out there that in fact demonstrate the inadequacy of this approach, like this one . I think I would go bag groceries before I would resort to jamming insert statements into a test setup. Really nice from a support/refactoring point of view especially.

      Updates - More light here (even if you use the TestNG classes, the setup sequence is wrong and already being arbitrated in their defect trackerů.)


      • #4
        I was having this problem and found a simple fix. My class had an extra constructor:

        public MyClassTest(String name) {

        When I removed this, the error went away.