Loading ...
Sorry, an error occurred while loading the content.
 

[XP] EJB and junit

Expand Messages
  • Gerd Boerrigter
    Hi, we are using WebLogic server to build Enterprise JavaBeans. I want to use junit to do unit tests of the beans. I am new to EJB and can not think about an
    Message 1 of 2 , Feb 28, 2000
      Hi,

      we are using WebLogic server to build Enterprise JavaBeans. I want to
      use junit to do unit tests of the beans. I am new to EJB and can not
      think about an easy way to test the beans in the container.

      It looks like I need to write a Remote-Interface for the tests to be
      able to run them on the server. This looks like too much work to do.
      Is there an easy way to run junit on the server? How do other people
      do it?

      Thanks for your help
      Gerd
    • Paul Hodgetts
      ... You test the beans just like you were writing any other client app. You get the home reference, and call the EJB methods. This works for both the command
      Message 2 of 2 , Feb 29, 2000
        Gerd Boerrigter wrote:

        > we are using WebLogic server to build Enterprise JavaBeans. I want to
        > use junit to do unit tests of the beans. I am new to EJB and can not
        > think about an easy way to test the beans in the container.

        You test the beans just like you were writing any other client
        app. You get the home reference, and call the EJB methods.
        This works for both the command line and JUnitRunner ways of
        running the tests. I do it all the time.

        > It looks like I need to write a Remote-Interface for the tests to be
        > able to run them on the server. This looks like too much work to do.
        > Is there an easy way to run junit on the server? How do other people
        > do it?

        First off, I don't even try to run the tests in the container.
        I either test the EJBs from a remote client, or I test the app
        server classes outside the container.

        I tend to make my EJBs be facades into the internal object model
        of the application. In other words, the EJBs tend to delegate
        most of their business logic to regular Java objects. The EJBs
        just handle making an object interface into a distributed
        component interface. This is good component design, anyway.

        Using this approach, I can test the internal object model apart
        from the app server and without introducing the distribution
        issues.

        For example, I have a business rules engine that cranks though
        some business rules and fires off logic when the trigger. I
        want the rules engine to be a distributed component. But first
        I write it as a non-distributed Java class (and all the other
        associated classes). I test it (all the classes) as such,
        in a "normal" VM environment. Then I write a rules engine
        session bean, that takes care of the distribution issues and
        then just delegates to the non-distributed rules engine. The
        session bean is pretty much just a distributed wrapper around
        the rules engine.

        To test the distributed version, it's really not a big deal to
        get the EJB home reference in the setUp method, and then have
        the individual test methods call the various session bean
        methods. It's just a dozen lines of code more than a
        non-distributed version of the TestCase. True, you need to
        start the app server to run these tests (I just clocked my
        WebLogic startup on NT at 70 seconds, so it's not that big a
        deal - if I wanted to test on the Solaris boxes it might take
        up to 5 minutes to deploy and start up, but I only do that at
        the end of the day as a sanity check).

        In theory, this is great, and in practice it works pretty
        well for session beans. Entity beans, especially when you're
        using container-managed persistence, are tougher to use as a
        wrapper, since their methods delimit the persistent load/
        store points, and the persistent data needs to be part of
        the EJB class. We also need the app server up in order to
        take care of the automated persistent mechanisms. So it's
        usually not worth the effort to try and test them out-of-
        container. But again, the distributed tests aren't much more
        than a non-distributed version.

        So granted, testing EJBs deployed in the app server add extra
        levels of dependencies and test complexity. I use WebLogic
        on NT for development, and I can fire up the app server, run
        a suite of EJB tests, and shut down the app server in less
        than 5 minutes. So the turn around time isn't all that bad
        and still lets me develop and integrate in cycles measured in
        less than an hour.

        Extreme Enterprise Java!

        -Paul Hodgetts
      Your message has been successfully submitted and would be delivered to recipients shortly.