Spring MVC的junit测试用例

Question

we are developing an application using spring mvc framework. I have given all the classes below, please suggest how to write a junit test case for the below scenario.

I want to write a junit test case for the validateAccountInformation(requestDTO) method which is called in validateAccount(..) method of LPAValidator.java class. Below is my junit test case followed by the java classes. Actual call goes from the LPAController.java as shown in the below code.

LPAControllerTest.java

       @Test(groups = "manual")
        public void submitRequestForLPAAccountTest()
        {
       // businessCalendar.nextBusinessDay(
      //                LocalDateHelper.today(), LPAConstants.TWENTY_BUSSINESS_DAYS)
     //i want to write the test case for the above commented logic, 
     //if business days is not equal to twenty days, test should fail. 
        }

LPAController.java

    @RequestMapping(value = "/lpa/{accNumber}/spread, method = RequestMethod.GET)
     public @ResponseBody LPAResponseDTO accountSearch(@RequestBody final LPARequestDTO clientrequestBody,
                                        @PathVariable final String accNumber, final HttpServletResponse response)
    {
        //some logic goes here

final LPAAccountResponse domainResponse = service.submitRequestForLPAAccount(requestBody);

    }

LPAServiceImpl.java

@PermitAll
@NonTransactional
public LPAResponse submitRequestForLPAAccount(final LPARequest requestDTO)
{
    return lpaRepository.submitRequestForLPAAccount(requestDTO));
}

LPARepository.java

    @PermitAll
    @NonTransactional
    public LPAResponse submitRequestForLPAAccount(final LPARequest requestDTO)
    {
    //some logic
    lpaValidator.validateAccount(requestDTO);

    //some logic

    }

LPAValidator.java -- java class for validations

@component
class LPAValidator{
    @Inject
    private BusinessCalendar businessCalendar;

            void validateAccount(final LPARequest requestDTO) throws Exception {
            try {
                validateAccountInformation(requestDTO);
                } catch(Exception e){
                }
        }

            private void validateAccountInformation(final LPARequest requestDTO) throws Exception{
                final accDate lpaAccDate = requestDTO.getLPADate();
                final LocalDate twentyBussinessDays = businessCalendar.nextBusinessDay(
                    LocalDateHelper.today(), LPAConstants.TWENTY_BUSSINESS_DAYS); //i want to write 
    //test case for this line of code, if business days given is more than twenty test should fail.
                //some logic here
        }

Please suggest what needs to be added in LPAControllerTest.java to test the nextBusinessDay(..) as discussed above.

Answer 1

You're trying to write an integration test in which your controller is called, which then calls all the subclasses until the validator is triggered. That is not a traditional 'unit test'.

A traditional unit test would just test the validator straight up, and nothing more.

Nevertheless, when writing an integration test, spring documentation to the rescue
In short, it'll require you to create an applicationcontext with all the necessary scaffolding, and then use a mockMvc call to do a GET on the created application.

If you want to test the validator, use simple mocking framework: See [ http://mockito.org] Gives you something like this:

@Mock BusinessCalendar businessCalendarMock;
@Mock LPARequest mockRequest;
@Mock accDate mockDate;
@Mock LocalDate mockLocalDate;
@InjectMocks LPAValidator lpaValidator = new LPAValidator();
@Test public void testValidateAccount() {
    when(mockRequest.getLPAdate()).thenReturn(mockDate);
    when(businessCalendar.nextBusinessDay(LocalDateHelper.today(),LPAConstants.TWENTY_BUSSINESS_DAYS).thenReturn(mockLocalDate);
    // continue your test from here
   lpaValidator.validateAccount( mockRequest);
   verify(businessCalendar).nextBusinessDay(LocalDateHelper.today(),LPAConstants.TWENTY_BUSSINESS_DAYS);
    // although if the use of mockLocalDate is integral to your code, it'll probably show before and no verify is necessary;