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

Re: Outside Mock Objects

Expand Messages
  • dip_bhatt
    Say you are testing the following method using mock objects: public ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request,
    Message 1 of 10 , Jul 31, 2002
    • 0 Attachment
      Say you are testing the following method using mock objects:

      public ActionForward perform(ActionMapping mapping,
      ActionForm form,
      HttpServletRequest request,
      HttpServletResponse response)
      throws IOException, ServletException


      it seems feasible to mock request and response objects, but what
      about mapping and form? i agree one has to know what this does. say
      the implementation processes the specified HTTP request, and creates
      the corresponding HTTP response (or forward to another web component
      that will create it). Returns an ActionForward instance describing
      where and how control should be forwarded, or null if the response
      has already been completed.

      what if the perform implementation throws a nullpointerexception at
      the middle of processing the mock objects? and you don't even know
      which statment threw that exception?

      Can you override this problem?

      Thanks,
      Dipal



      --- In extremeprogramming@y..., "Steve Freeman" <steve@m...> wrote:
      > From: "Niclas Olofsson" <gurun@a...>
      > To: <extremeprogramming@y...>
      > Sent: Tuesday, July 30, 2002 6:14 PM
      > Subject: Re: [XP] Outside Mock Objects
      >
      >
      > > A downside of doing it this way is that you have to know the
      spec. You
      > > can't just make a mock of a Servlet session implementation without
      > > knowing what the expected behavior is. If you do it wrong, it's
      destined
      > > to break as soon as you deploy it. But I like to know what I'm
      doing, so
      > > I don't think of it a problem... Most of the time, mocking an API
      can be
      > > very educating. You learn what objects deal with logic, and which
      deal
      > > only with data. The ones that deals with logic is the once you
      will
      > > mock, the other ones you just use as is.
      >
      > Not sure I understand the last line, but it's very true that one of
      the
      > benefits of stubbing or mocking is that you have to figure out what
      the real
      > code does.
      >
      > > However, most of the time, if provided with an interface I do
      anonymous
      > > mock implementations right in the tests.
      > >
      > > None of this is probably (in the general publics eye) the correct
      way of
      > > doing neither testing or mocking. But as I said, it works for me.
      And
      > > the day it doesn't work anymore I guess I'll refactor my strategy.
      >
      > I find myself moving towards inline mocks a lot more these days
      (maybe
      > something to do with moving off VisualAge?). Depends on the
      situation and
      > whether I need the mock implementation in multiple places. If I do
      that,
      > however, I have to work a bit harder to keep the tests readable. The
      > Expectation library helps a lot with this.
      >
      > Steve
    Your message has been successfully submitted and would be delivered to recipients shortly.