웹 부분중 표현부분에 대해 어떻게 TDD가 진행될까? 
----
처음 코드는 이러했다.

http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/action/ViewPageAction.py?rev=1.5&content-type=text/plain

즉, 현재 action 코드에 다 섞여있는 것이다.이부분을 TDD로 작성하기 위한 테스트는 다음과 같았다.

http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/test_viewpageaction.py?rev=1.2&content-type=text/plain

즉, 일종의 Template Method 의 형태로서 Testable 하기 편한 ViewPageAction 의 서브클래스를 만들었다. 어차피 중요한것은 해당 표현 부분이 잘 호출되느냐이므로, 이에 대해서는 서브클래스로서 텍스트를 비교했다.

그러다가, 최근 프로젝트 하는중에 ModelViewPresenter 라는 개념에 대해 익히게 되었다. 정확한 개념에 대해서는 잘 잡지를 못했지만, HumbleDialogBox 라는 아티클을 보니 대강 감이 온것 같았다. 중요한 건 표현부분에 대해서 가능한한 로직이 남지 않아야 한다는 점이고, 표현부분을 사용하는 쪽 입장에서도 가능한한 추상화레벨이 높은 메소드를 쓸 수 있어야 한다는 점이다. 

암튼, 현재의 내 코드로 봤을때는 기존의 MVC 로 봤을 때에도 View와 Controller 가 섞여있는 형태였다. 이 부분에 대해서 다음과 같이 코드를 변경해보았다.

http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/action/ViewPageAction.py?rev=1.6&content-type=text/plain

http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/viewpresenter.py?rev=1.1&content-type=text/plain
presenter 부분은 추후 내부적으로 Template 엔진을 사용하는 방향을 생각해 볼 수도 있을것 같다.

이렇게 될 경우 테스트 코드는 다음과 같다. 여차하면 테스트 코드에서 presenter 를 사용할 수도 있었다. (어차피 ViewPageAction 역할을 잘 하느냐가 중요하니까, 거기에 붙는 HTML 들이 어떠하냐가 중요하진 않을것이다.)

http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/test_viewpageaction.py?rev=1.3&content-type=text/plain

하지만, 이건 리팩토링 단계에서의 이야기고, 만일 새 코드를 작성하는 중의 UI 부분 presenter 를 TDD로 구현한다면 어떻게 될까? 아마 저 MockViewPresenter 부분이 먼저 구현되고, 이 인터페이스를 근거로 ViewPresenter 를 만든 뒤 HTML 코드 부분을 작성하면 될 것 같다. 실제 UI 에 어떠어떠한 것이 표현되느냐는 AcceptanceTest 단에 맡기면 되리라. 

다음부터 action 부분을 작성한다면?

 1. action test 를 만든다. (생각해보건데, action 에서의 Servlet 부분이 있는 곳 또한 얇게 만들 수 있겠다는 생각을 해본다.) 
 2. MockPresenter 를 만든다. 중요한 것은 출력결과를 테스트하는것이 목적이 아니라 action 결과 행해지는 일들(Transaction)이 제대로 일어났는지를 테스트하는 것이다. MockPresenter 는 그냥 해당 메소드들이 호출되었는지만 verify 하는정도면 충분할 것이다.
 3. MockPresenter 를 근거로 Real Presenter 를 만든다.

See Also HumbleDialogBox

--[1002]