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

[XP] Re: Testing EJB

Expand Messages
  • Hans Wegener
    ... To extend the point - it s all about testing framework extensions. The only workable solution I have come across is separate application functionality
    Message 1 of 2 , Mar 1, 2000
    • 0 Attachment
      > It is also something similar to what I have been doing
      > with testing servlets.

      To extend the point - it's all about testing framework extensions. The only workable solution I have come across is separate "application functionality" from "framework integration code," and then unit-test the functionality in isolation (easy). The trick is to design the application in a way that the integration code is very lightweight and "foolproof," i.e. that there can't be any hard to track down bugs.

      HW
      --
      Phone: +41 (1) 364 03 14
      Mobile: +41 (76) 329 03 14
      Mail: hans.wegener@...
    • Tim Mackinnon
      ... out I would suggest that Mocking up objects that conform to the required interface isn t as much work as you think. When we were testing Servlets, my
      Message 2 of 2 , Mar 1, 2000
      • 0 Attachment
        > 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

        I would suggest that Mocking up objects that conform to the required
        interface isn't as much work as you think. When we were testing Servlets, my
        partner (Oli Bye) rose to the challenge of my complaints and generated
        MockServletResponse/Request objects in front of my eyes (its actually quite
        easy in Visual Age - you just need the courage to do it).

        The trick however, is to not get sucked into writing "Real" implementations
        of these objects, they should be totally phake and have no fancy
        implementations, just plain instance variables that return hard coded/or
        collection set results.

        I would think that this approach would be acheivable even with EJB
        implementations (unless they have done some nasty singleton
        implementations). Once you do it, you get a very reliable way to test your
        code - you also get an easy way to introduce controlled failures. Of course,
        after this you then need some functional/system style testing to actually
        try it with the real environment, but at this point your code should be
        quite solid. The code presented by someone for testing in the live
        environment would be the type of thing that you would run at this point
        (although not as frequently as the Mock unit tests).

        Tim
      Your message has been successfully submitted and would be delivered to recipients shortly.