스프링 2.5 @MVC 컨트롤러 테스트관련 궁금한거..

@Controller
@RequestMapping(“board/*.do”)
@SessionAttributes(value=”board”)
public class BoardController {

    @Autowired
    private BoardService boardService;

    @Autowired
    private BoardValidator validator;

    @RequestMapping
    public void list(ModelMap model){
        model.addAttribute(boardService.getAll());
    }

    @RequestMapping(method=RequestMethod.GET)
    public void add(ModelMap model){
        model.addAttribute(new Board());
    }

    @RequestMapping(method=RequestMethod.POST)
    public String add(@ModelAttribute(“board”) Board board, BindingResult result, SessionStatus status){
        validator.validate(board, result);
        if(result.hasErrors())
            return “board/add”;
        else{
            this.boardService.saveOrUpdate(board);
            status.setComplete();
            return “redirect:board/list.do”;
        }
    }

    @RequestMapping
    public void delete(int id){
        boardService.deleteById(id);
    }

}

위 코드는 간단한 스프링 2.5 @MVC 컨트롤러입니다. CRUD 중에서 U 관련 코드는 생략했습니다.

이 컨트롤러를 작성하면서 확인하고 싶었던 걸 정리하면 다음과 같습니다.
1. board/list.do 라는 요청 결과를 보여줄 뷰는 WEB-INF/board/list.jsp 파일이 맞는지..(ViewResolver 확인)
2. board/list.do 라는 요청을 했을 때 결과 뷰에 넘어가는 모델 객체 중에 List<Board>가 있는지. 그리고 그 모델 객체의 이름이 boardList가 맞는지.(ModelAndView 확인)
3. board/add.do GET 요청이 오면 저 컨트롤러의 add(ModelMap) 메소드가 호출되는지.(RequestMapping 확인)

이 때 2번은 쉽게 테스트가 가능합니다. 인자로 넘겨주는 ModelMap 객체를 하나 만들어서 넘겨주고 해당 메소드를 호출 해보고 ModelMap 객체를 뒤져보면 테스트 하고자 하는 데이터를 찾을 수 있습니다.

그러나.. 1번은 ModelAndVIew 객체를 반환하도록 컨트롤러 코드를 고치지 않는 이상 어떻게 테스트 할 수 있을지 감이 안잡힙니다. 스프링 MVC CoC를 적극 활용하려고 작성한 코드인데 명시적으로 뷰이름을 설정해버리면 그런 의도가 무색해지니까요..

3번도 마찬가지 입니다. 이건 더 감이 안 잡힙니다. 테스트를 할 때 만드는 ApplicationContext가 WebApplicationContext도 아니라서 스프링이 기본으로 등록해주는 빈(request handler, adapter 등)들이 없을 것이기 때문에 스프링 테스트만 가지고는 테스트가 어려울 것 같다는 생각이 듭니다.

어쩌면 컨트롤러 테스트가 아닐 수도 있겠습니다. 스프링 프레임워크가 제공하는 기능에 대한 테스트일 수도 있으니 스프링 코드에서 뷰 리졸버와 요청 맵핑 클래스에 대한 테스트로 만족하고 넘어갈 수도 있겠지만.. 글쎄요. 그래도 왠지 테스트가 하고 싶네요. 혹시 HttpUnit으로 이런걸 할 수 있는건가요. 써보지 않았는데.. 함 살펴봐야겠습니다.

4 thoughts on “스프링 2.5 @MVC 컨트롤러 테스트관련 궁금한거..”

  1. 지금 원하는 테스트의 목적은 @MVC에 포함된 convention에 대한 테스트지 저 Controller 클래스의 테스트가 아니지. 스프링의 mock등을 잘 활용하면 web container 밖에서도 테스트가 가능하고, 그것은 스프링 자체의 테스트 코드를 참조할 것. 기억이 가물가물해서..

    사실상 애플리케이션 개발이라면 convention에 대한 체크는 원칙적으로 프레임워크 레벨에서 단위테스트가 되고, 그것이 동작한다고 가정하고 만드는 것이 맞고. 구지 검증하자면 그때는 웹테스트와 같은 in-container 테스트를 수행할 수 밖에 없겠지.

    딱 view resolving 이름을 테스트 하고자하자면, 프레임워크 내부 메카니즘을 변경해서 테스트하는 방법이 있겠지만 과연 그게 필요할지는? 스프링 공부차원이라면 머…

    Convention이 적용된 테스트는 그 범위를 잘 생각해볼 필요가..

    1. 네.. 프레임워크가 제공하는 컨벤션이나 기능(view resloving)은 프레임워크의 테스트를 믿고 가는게 좋겠네요.

      흠.. RequestMapping에 대한 테스트는 그래도 꼭 해보싶은데… 아마 스프링 테스트 코드에 단서가 있을 것 같네요.

      감사합니당~

  2. 어쩌다 보니 저도 프레임웍에 대한 테스트를 해버리고 말았다는 생각이 드네요 ;ㅋ
    단위테스트에 대한 스킬부족으로 인한 삽질을 하고 나서야 ;;
    테스트는 이런것들이 잘못되었구나 싶었고..

    오늘 기선님이 말이 그러한 부분들은 따로 빼서 테스트 해보는것도 좋은 방법인것 같습니다^^;;
    이제서야 이 포스트 내용에 대해서 .. 머가 먼지 이해가 갈듯합니다.ㅋ
    이상 무지한 1人이 었습니다. 꾸벅;;

    1. ㅎㅎ뭘요. 저도 잘 몰라요.
      이렇게도 해보고 저렇게도 해보고.. 그러면서 조금씩 나아지는 거겠죠. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *