Kartik
Kartik

Reputation: 2609

Minimizing object retention during unit tests

I have a question about memory management/memory leaks that I would like clarification on.

Set Up:

I am testing some servlet code that takes HttpServletRequest and HttpResponse objects references HttpServletRequest#getParameter(String), HttpServletRequest#getHeader(String) and HttpServletRequest#getAttribute(String).

I am writing unit tests for the servlet code. To allow testing, I have created stubs for HttpServletRequest and HttpServletResponse that would allow for testing. The sample code is given below:

public final class HttpServletRequestStub implements HttpServletRequest {

  private Map<String, String> parameterMap = new HashMap<String, String>();
  private Map<String, String> headerMap = new HashMap<String, String>();
  private Map<String, String> attributeMap = new HashMap<String, String>();

  public void setParameter(String param, String value) {
    this.parameterMap.put(param, value);
  }
  public void setHeader(String param, String value) {
    this.headerMap.put(param, value);
  }
  @Override
  public void setAttribute(String param, String value) {
    this.attributeMap.put(param, value);
  }
  public void flush() {
     this.parameterMap.clear();
     this.headerMap.clear();
     this.attributeMap.clear();
  }

  @Override
  public String getParameter (String parameter) {
    return this.parameterMap.get(parameter);
  }
  @Override
  public String getHeader(String parameter) {
    return this.headerMap.get(parameter);
  }
  @Override
  public String getAttribute(String attribute) {
    return this.attributeMap.get(attribute);
  }

   .... Other stubbed methods




}

In my unit test:

public class MyTest {
   private MyServlet servlet;

   private HttpServletRequest request;

   private HttpServletResponse response;

   @Before
   public void setUp() throws Exception {
      request = new HttpServletRequestStub();
      response = new HttpServletResponseStub(); // Not in the sample code but implemented.
      servlet = new MyServlet();
   }

   @After
   public void tearDown() throws Exception {
      request = null;
      response = null;
      servlet = null;
   }

  @Test
  public void testFoo() throws Exception {
     request.setParameter("foo", "bar");
     request.setAttribute("attrib", "attrib");
     request.setHeader("header", "header");
     servlet.service(request, response);
  }


}

My question is regarding memory management. Is is necessary for me to flush the fake header, request and attribute map contents after test execution or would it happen automatically once the request , response objects are dereferenced in my tear down method (annotated with @After)?. Would I have to call the flush method explicitly in my tear down method to clear memory references? I thought I might need to set up inweak references for stub maps using Weak HashMap instead of HashMap but I don't know if this is right choice. I read through this article and it is still not clear. Any assistance would be useful.

Thanks,

Kartik

Upvotes: 1

Views: 241

Answers (2)

卢声远 Shengyuan Lu
卢声远 Shengyuan Lu

Reputation: 32004

Due to unit test independency, JUnit creates new MyTest object for each test method.

That is, testFoo() and testBar() are invoked in different MyTest instances. Your code is enough to memory issue, even tearDown() is not necessary in this case. Since previous MyTest instance is available to GC, its members are also be available to GC, if nothing else reference them.

Upvotes: 0

AlexR
AlexR

Reputation: 115328

Dereferencing of object should be enough. Java garbage collector removes all objects that cannot be accessed, i.e. there are no references that help access them. If you have doubts that your objects really gone you can use any of available java profilers.

BTW, may I advise you to use one of available implementations of Mock objects instead of implementing stuff like SerbletRequestStub yourself? See EasyMock for example. And one more advise. There are JUnit extensions that already implement all web related stubs. See Apache Cactus.

Upvotes: 1

Related Questions