Announcement Announcement Module
Collapse
No announcement yet.
Testing a Class that uses lookup-method injection Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing a Class that uses lookup-method injection

    I have a class that uses lookup method injection to override some methods to get a new instance of a class each time it is called.
    I've been having trouble locating a good way to test out this class with junit.

    Code:
    public class ContextInterceptor extends HandlerInterceptorAdapter {
    
        public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
            RequestContext requestContext = null;
            if (ServletUtil.isWebRequest(request)) {
                requestContext = getWebRequestContext();
            } else {
                requestContext = getWapRequestContext();
            }
            
            if (requestContext != null) {
                request.setAttribute(RequestContext.REQUEST_ATTRIBUTE, requestContext);
                return true;
            } else {
                return false;
            }
        }
    
        //  this method will be overridden using spring method lookup injection
        public RequestContext getWapRequestContext() {
            return null;
        }
        
        //  this method will be overridden using spring method lookup injection
        public RequestContext getWebRequestContext() {
            return null;
        }
    }
    I'd like to test out the preHandle method, and also be able to control the RequestContext objects that preHandle is ultimately going to set into the request.

    Anyone come up with a good way to test out classes that use lookup method injection?

  • #2
    Anyone come up with a good way to test out classes that use lookup method injection?
    You can try sub-classing ContextInterceptor and overriding the 'lookup method injection' method just for your test.

    Comment


    • #3
      Thats what I would do

      Comment


      • #4
        or use mocks (see easy mock).

        Comment


        • #5
          Originally posted by costin
          or use mocks (see easy mock).
          Does EasyMock work on regular and abstract classes? I thought it was just for Interfaces.

          -Justin

          Comment


          • #6
            Yes it does - check out their sites. You need to download an additional jar which through bytecode instrumentation (aka CGLIB) extends your classes

            Comment


            • #7
              Originally posted by costin
              Yes it does - check out their sites. You need to download an additional jar which through bytecode instrumentation (aka CGLIB) extends your classes
              Awesome, I'll have to check it out. Their site (easymock.org) is a little lean on the documentation but I'll do more digging to try to learn how do to it.

              Comment


              • #8
                Found the documentation for it:
                http://www.easymock.org/ClassExtensi...mentation.html

                Requires Java 5, and I'm on 1.4.2 still. Hmm. Oh well.

                Comment


                • #9
                  The name of the package is EasyMock Class Extension. Don't be fooled by their site - it's pretty clean and short because working with the easymock is easy. You have to work with the javadoc in front at the beginning but afterwards you get used to it.
                  The only problems that I got were with errors from mock not properly set up but the mailing list is the perfect place for that.

                  Comment


                  • #10
                    Use 1.2 versions - there is a good explanation on the site about the differences between them. I use also JDK 1.4.2.
                    Btw, easy mock is also used by Spring for testing. Convinced?

                    Comment


                    • #11
                      Originally posted by costin
                      Use 1.2 versions - there is a good explanation on the site about the differences between them. I use also JDK 1.4.2.
                      Btw, easy mock is also used by Spring for testing. Convinced?
                      Heh jeez, now I see it
                      Thanks for your help, I'll give that a shot.
                      -Justin

                      Comment


                      • #12
                        or use mocks (see easy mock).
                        It's true EasyMock will work for classes, but I tend to only use mocks for Collaborators, not the actual class I'm testing. In this scenario, I'd still subclass ContextInterceptor.

                        Comment


                        • #13
                          Generally speaking, mocking interfaces is the preferred way

                          You can mock classes (with cglib) so long as they are not final and do not contain any final methods in them.

                          I don't really get how using mocks in this instance helps anyway AFAIK you cannot "partially" mock a class, so you couldn't create a class where the get*RequestContext was mocked, but the preHandle was native code. You either have a "native" class, or a mocked class.

                          Maybe I am missing something

                          Comment


                          • #14
                            I don't really get how using mocks in this instance helps anyway Smile AFAIK you cannot "partially" mock a class, so you couldn't create a class where the get*RequestContext was mocked, but the preHandle was native code. You either have a "native" class, or a mocked class.
                            You can use delegation so basically the methods you don't require simply delegate to the parent class. Moreover you can finalize the methods you don't want to extends, CGLIB will just throw a warning and that's all.
                            Indeed in this case you'd better off extending the initial class but mocking is sometimes better because you can mimic the behaviour without wiring the colaborators as you are in charge of your object behaviour (without the need of rewriting it 'per-se').

                            Comment


                            • #15
                              So if you mock a class, the methods you don't explictly mock just fall through to the native class?

                              Thats's pretty cool. I only ever mock interfaces, so it isn't really a problem for me

                              Comment

                              Working...
                              X