ologist`s blog2.0

과거에 struts의 action을 테스트를 하기 위해서 mock을 만들어 주는 오픈소스나 라이브러리를 다운받아서 스터디를 하고, 써본 경험이 다들 있을 것이라고 생각을 한다. Junit Recipe에서는 심지어 EJB까지 mock을 만들어서 테스트를 한다. 그 책을 보면, 테스트 못할 것이 정말 없다.

하지만, 이런 작업자체가 귀찮다고 느껴지지 않은가? 물론 mock을 아예 쓰지 말자는 얘기는 아니다. mock을 조금만 사용을 하고, 테스트를 용이하게 해보자는 것이다. 특히 서블릿 종속적인 API에서 벗어나 보자는 얘기를 하고 싶다.

왜, struts는 자신들이 아키텍쳐를 포기하면서, webwork기반의 struts2.0을 만들었을까? 사실상 struts는 이름만 남아있다고 해야 한다.

webwork의 장점 중의 하나가 Action마져도 POJO스타일을 유지 할수 있다는 것이다.

웹에 대한 정보나 서블릿에 대한 정보를 모두 interceptor를 활용을 해서 쿠키나 reuest에 대한 정보를 서블릿API에 종속적이지 않게 Action을 만들수 있는 것이다.

이 기법은 Adapt Parameter와 비슷하다. 하지만, 나같은 경우는 Fake인터페이스를 만들고 인터페이스를 변경하는 형태가 아니라, 쿠키값을 Map통해서 Action에 inject를 하고, action안에서 사용할 비즈니스로직이 도메인에 populate를 해주었다.

Action에서 setCookieMap(Map map)이라는 인터페이스가 생겼다. interceptor에서 key,value쌍으로 쿠키의 정보를 map에 넣어주는 형태인 것이다.

Cookie와 같은 서블릿 API는 Action에 존재를 하지 않고, interceptor에서만 서블릿API에 종속적인 코드가 들어가는 것이다. 물론, interceptor는 aspect적으로 필요한 로직들을 모듈화 시켜둔 것이고, 많은 action에서 재사용이 가능하다.

이것은 무엇을 의미를 하는가? Action을 new로 생성을 해서 파라미터 셋팅과 DI를 하면 바로 http에 대한 mock이 없이 테스트를 할수 있다는 것이다.


지난 주에는 Action테스트를 만들면서, Action존재하는 XXXContext를 다 제거했다.

ThreadLocal기반의 XXXXContext클래스를 좀 과용해서 서본적이 있었는데, 역시나 전역 객체(?) or 클래스는 코드의 가독성을 떨어뜨리고, 이해하기도 어렵다.

사용할 때는 웬지 편안하게 쓰는 듯 하지만, 사용한 곳에서 XXXContext를 제거하기 시작을 해봐라. 힘든 만큼 디자인이 좋지 않다는 것을 뜻하는 것이다.

뜬금없이 전역객체에 setter를 하고 다른 객체에서 비즈니스 로직을 처리하는 해괴한 행위를 안 할수 있게 된것이 가장 기쁘다.



P.326을 보면, 약간의 기법이 틀리기는 하지만, 목적은 비슷한 것을 볼수가 있다. dependency break작업은 더 가독성이 좋은 코드, 더 쉬운 유지보수, 테스트를 위해서 신경을 써줄수록 더욱 좋다.