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

[XP] Testing EJB

Expand Messages
  • Gareth Reeves
    This came up at the XPImmersionTwo course today. It is also something similar to what I have been doing with testing servlets. The servlet problem: The
    Message 1 of 4 , Feb 29, 2000
    • 0 Attachment
      This came up at the XPImmersionTwo course today.

      It is also something similar to what I have been doing with testing
      servlets.

      The servlet problem:
      The functionality of my servlets relies on some of the services that the
      servlet engine provides. The servlet engine creates the HttpServletRequest
      and HttpServletResponse and passes them to the servlet when executed. These
      objects are the way to get information in and out of the servlet. The
      servlet is rendered useless without these objects. The servlet engine offers
      other services like session management, the use of those services needs to
      be unit tested.

      Testing EJBs (same problem):
      To test these things we need to replace these APIs with a testable
      implementation. Polymorphism (thanks Uncle Bob). But... I can't imagine
      anyone is going to implement EJB API's just for testing.

      I was able to do implement the JSDK API's for testing by reusing a lot of
      code from a real servlet engine that I had been working on, this worked out
      quite well. Maybe there is a open source EJB container out there that can be
      leveraged for testing purposes.

      There is a very fine line here between Unit testing and Functional testing
      and I want to be careful not to cross it. I think that in general Functional
      tests can be implemented using the real container or servlet engine, however
      this is usually not appropriate or not possible for Unit tests.

      So again, the problem is, how do we unit test the code that relies on a
      service provided by a container? Dummy implementations of those services can
      be created but in EJB's case I think this is an unrealistic amount of work.
      The JSDK API was a significant amount of work even with a 50% code reuse.

      Any comments are appreciated.

      I will make the JSDK API code available to anyone who thinks they can make
      good use of it.

      Happy Testing

      Gareth


      ------------------------------------------------------
      'Sufficient to the day are the troubles thereof'
    • Kent Beck
      I kind of hate to bring this up, but my first strategy for testing something as complicated as EJB is to use simpler technology. If you can solve your problem
      Message 2 of 4 , Mar 1, 2000
      • 0 Attachment
        I kind of hate to bring this up, but my first strategy for testing something
        as complicated as EJB is to use simpler technology. If you can solve your
        problem with something simpler, like servelts and a mapping tool, or even a
        raw active database, do it. EJB is enormously complicated, the
        implementations of the cool stuff is dodgy at best, and there's a whole lot
        there that I've never needed.

        Kent
      • Joshua Kerievsky
        ... I would say that your design strategy is to choose simple technology first. I view that as core to XP. It is certainly core to how I design software, and
        Message 3 of 4 , Mar 1, 2000
        • 0 Attachment
          >I kind of hate to bring this up, but my first strategy for testing something
          >as complicated as EJB is to use simpler technology. If you can solve your
          >problem with something simpler, like servelts and a mapping tool, or even a
          >raw active database, do it. EJB is enormously complicated, the
          >implementations of the cool stuff is dodgy at best, and there's a whole lot
          >there that I've never needed.

          I would say that your design strategy is to choose simple technology first.
          I view that as core to XP. It is certainly core to how I design software,
          and it effects what technologies I choose to learn and use.

          I wrote about this in an email to this list about a month ago -
          unfortunately, a few folks decided to turn the message into a Perl debate.
          Well, I'll add to your Servlet recommendation: also consider Perl.

          regards
          jk


          _______________________________
          Industrial Logic, Inc.
          Joshua Kerievsky, founder
          mailto:joshua@...
          http://industriallogic.com
          415-292-6266
          415-292-6267 (fax)
        • Gareth Reeves
          I agree with you both on choosing simple technologies and simple solutions. EJB could be considered a simple technology becuase it saves us having to write a
          Message 4 of 4 , Mar 1, 2000
          • 0 Attachment
            I agree with you both on choosing simple technologies and simple solutions.
            EJB could be considered a simple technology becuase it saves us having to
            write a whole bunch of complex stuff (ConnectionPooling, Persistence etc).

            Further more, the problem here is not the complexity of system itself it is
            the complexity of what is required to test.

            I think these testing issues need to be overcome so that it is possible to
            implment EJB solutions using XP. If not, where is XP heading?

            Gareth

            -----Original Message-----
            From: Joshua Kerievsky [mailto:joshua@...]
            Sent: Wednesday, March 01, 2000 11:16 AM
            To: extremeprogramming@egroups.com
            Subject: [XP] Re: Testing EJB


            >I kind of hate to bring this up, but my first strategy for testing
            something
            >as complicated as EJB is to use simpler technology. If you can solve your
            >problem with something simpler, like servelts and a mapping tool, or even a
            >raw active database, do it. EJB is enormously complicated, the
            >implementations of the cool stuff is dodgy at best, and there's a whole lot
            >there that I've never needed.

            I would say that your design strategy is to choose simple technology first.
            I view that as core to XP. It is certainly core to how I design software,
            and it effects what technologies I choose to learn and use.

            I wrote about this in an email to this list about a month ago -
            unfortunately, a few folks decided to turn the message into a Perl debate.
            Well, I'll add to your Servlet recommendation: also consider Perl.

            regards
            jk


            _______________________________
            Industrial Logic, Inc.
            Joshua Kerievsky, founder
            mailto:joshua@...
            http://industriallogic.com
            415-292-6266
            415-292-6267 (fax)


            ------------------------------------------------------------------------
            To Post a message, send it to: extremeprogramming@...
            To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...
            Ad-free courtesy of objectmentor.com

            ------------------------------------------------------------------------
            -- Easily schedule meetings and events using the group calendar!
            -- http://www.egroups.com/cal?listname=extremeprogramming&m=1
          Your message has been successfully submitted and would be delivered to recipients shortly.