2

I need to test the following code using JUnit. It looks complex to me and I am not even sure where to take a start from.

I know what the method is doing but I am unable to write a JUnit test for it. Do we follow a pattern or keep some key points in mind while testing any piece of code.

protected WebResource.Builder applyHeaders(WebResource service, List<? extends BaseClientHeader<?>> headers, List<HttpRequestClientHeader> httpHeaders) {
        WebResource.Builder wrb = service.getRequestBuilder();
        if( headers != null ) {
            for( BaseClientHeader<?> header : headers ) {
                wrb = wrb.header( ((IEnum)header.getName()).value(), header.getValue() );
            }
        }

        if( httpHeaders != null ) {
            for( HttpRequestClientHeader header : httpHeaders ) {
                wrb = wrb.header( header.getName().value(), header.getValue() );
            }
        }

        return wrb;
    }

Thanks,

Micho
  • 3,929
  • 13
  • 37
  • 40
  • If you're intimidated by testing a method break it up into smaller methods and test the individual pieces. – Zarwan Sep 01 '15 at 02:58
  • If you can get a copy of http://www.amazon.in/Working-Effectively-Legacy-Robert-Martin/dp/0131177052, that will help – Jayan Sep 01 '15 at 03:03
  • I know how to use JUnit and test methods but when it comes to testing API's or methods that call other methods internally make me confuse. –  Sep 01 '15 at 03:05
  • I thought SO do not accept opinion based question... – Ferdinand Neman Sep 01 '15 at 03:21
  • @syed Have you taken a look at [mockito](http://mockito.org)? It allows for mocking out other objects and calls that you want to control the behavior of. It may help your situation. – Rohan Sep 01 '15 at 04:21
  • @Rohan thanks for your advice and i have used Mockito to mock objects while testing API's but what i actually want to understand is that if we follow a standard way while testing our codes.For instance to test a simple method which returns a String is pretty straight forward but while testing a method that calls another method and that method calls another method in this situation what should i do. Do i need to understand the logic 100% or there is some sort of standard to follow while testing complex code. –  Sep 01 '15 at 04:39
  • @syed: In unit testing you have to test the smallest piece of code regarding a specific functionality. If you are testing larger pieces of code then you are probably doing integration testing. Check this SO question about the differences of unit and integration testing: http://stackoverflow.com/questions/4904096/whats-the-difference-between-unit-functional-acceptance-and-integration-test – Master_ex Sep 01 '15 at 05:04
  • Thank you all. Now i am getting it. I think i just need more practice and experience to understand this topic deeply. Thank you all once again. –  Sep 01 '15 at 14:38

1 Answers1

0

Even when this method looks like it does many different things and interacts lots of other code it should be rather simple to test; that’s because it only operates on objects that you hand in. Let’s see…

@Test
public void requestBuilderIsReturned() {
     WebResource webResource = Mockito.mock(WebResource.class);
     WebResource.Builder webResourceBuilder = mock(WebResource.Builder.class);
     when(webResource.getRequestBuilder()).thenReturn(webResourceBuilder);

     WebResource.Builder createdBuilder = objectUnderTest.applyHeaders(webResource, null, null);

     assertThat(createdBuilder, is(webResourceBuilder));
}

That was pretty straight-forward. In order to verify correct operation on both kinds of headers you need to get a bit tricky, I suppose:

    when(webResourceBuilder.header(anyString(), anyString())).thenReturn(webResourceBuilder);

This will simply make the header() method return the object it’s called upon. After that it should be quite simple to verify that the correct methods were called:

    verify(webResourceBuilder).header("header1", "value1");
    verify(webResourceBuilder).header("header2", "value2");

Armed with this you should be able to unit test the shit out of this particular method. :)

Bombe
  • 81,643
  • 20
  • 123
  • 127