1 Reply Latest reply on Feb 24, 2007 9:43 PM by Ian Hlavats

    SeamTest, Embedded EJB and TestNG issue

    Ian Hlavats Newbie


      I searched the forum before posting this but could not find a solution to this issue.

      I'm not sure how other developers are testing their Seam/JSF applications but in my case I have dozens of test classes with hundreds of test methods that I would like to run as a single test suite.

      The issue is that SeamTest initializes the embedded EJB container for each test class, and the embedded EJB container tries to create a connection pool-backed datasource but sometimes this fails and results in a variety of other side-effects and problems that cause my unit tests to fail.

      For example, an EJB that needs the EntityManager won't get this dependency because the underlying datasource has not been created. Therefore this EJB is not fully initialized by @In(create=true) and cannot be injected into other EJBs, resulting in a cascade effect of null-pointer exceptions and other problems.

      A common problem is that the connection pool cannot acquire a database connection and times out, causing transactions to rollback. This is time consuming and really derails the testing process! :-)

      Is there some reason why the EJB container needs to be initialized per class? Is this is a "lowest common denominator" approach because not everyone is going to be running TestNG suites, but everyone who uses SeamTest is going to be using TestNG classes?

      If so, I can understand this but how can users that run test suites benefit from SeamTest?

      I tried to override SeamTest.init() and SeamTest.cleanup() using TestNG's @Configuration(beforeSuite=true) and @Configuration(afterSuite=true) but this had other side-effects that I'm sure were not intended, eg. external context et. al. are not re-initialized for the second test class.

      Ideally (in my case) SeamTest would init the EJB container once and only once when the test suite starts and shut it down when the test suite ends. I think this would dramatically increase unit testing performance and shorten the testing cycle considerably since the significant overhead of starting/stopping the EJB container is incurred only once per test suite.

      SeamTest could provide a way for subclasses to choose a testing style. For instance, it could define two protected methods: isContainerNeededPerTestClass() and isContainerNeedPerTestSuite(). The default behavior could be container per test class but users like myself could use the container per test suite mode as needed.

      Thanks for your time.


        • 1. Re: SeamTest, Embedded EJB and TestNG issue
          Ian Hlavats Newbie

          More info:

          It turns out that after testing with two different connection pools, the underlying problem is a java.sql.SQLException ("No suitable driver").

          This only shows up for the second test class. The first one gets a connection just fine and my tests pass.

          I still vote for the container per suite option, but if someone has any tips on dealing with this short term issue I'm having that would be great.

          Why is the driver class not found for the second test? How does the TestNG suite classpath work? My driver is definitely on the classpath of my Eclipse projects.

          In addition, I tried classloading the JDBC driver explicitly before each test method, but to no avail.

          Any thoughts on what could be causing this?