jMock과 EasyMock을 비교하다 보니 예전에 번역했던 마틴 파울러의 글이 생각나 찾아 보았다. 인터페이스의 스타일은 Fluent Interface를 좋아하지만, 아직 Mock Object를 사용한 테스트에 익숙하지 않아서인지 프로그래밍 절차가 두드러지게 노출되는 EasyMock의 스타일이 적당해보인다.
Fluent Interface는 DomainSpecificLanguage에 적합하다. 만일, Mock Object를 사용한 테스트라는 도메인 익숙하다면, jMock의 Fluent Interface가 더 끌릴 것이다. 아무 익숙한 개념에 대해 기술하는 경우라면, 프로그래밍 절차가 두드러지게 노출되는 EasyMock의 스타일은 뻔한 내용을 줄을 나눠가면서 길게 작성하는 지루한 일이 될 것이다.
더 극명하게 이해할 수 있는 예를 들어보자. 아래 코드가 EasyMock의 방식이고
mockFoo.bar(arg);
ctrl.setReturnValue(1);
ctrl.replay();
아래가 jMock의 방식이다.
mock.expects(once()).method("bar").with(same(arg)).will(returnValue(1));
가독성(readability) 관점에서 평가는 상반될 수 있는 극명한 차이를 보인다. 마치 초보자도 쉽게 사용할 수 있는 단순하고 직관적인 UI(User Interface)와 한번에 모든 것을 처리할 수 있는 단축키가 풍부한 UI 중에 무엇이 좋으냐를 고르는 것 같은 기분이다. :)
사용자 인터페이스나 프로그래밍 인터페이스나 다음의 상충 관계의 균형을 고려하는 것은 동일하게 적용할 수 있을 것 같다:
낮은 학습 비용 vs 업무(프로그래밍)의 생산성
Fluent Interface는 DomainSpecificLanguage에 적합하다. 만일, Mock Object를 사용한 테스트라는 도메인 익숙하다면, jMock의 Fluent Interface가 더 끌릴 것이다. 아무 익숙한 개념에 대해 기술하는 경우라면, 프로그래밍 절차가 두드러지게 노출되는 EasyMock의 스타일은 뻔한 내용을 줄을 나눠가면서 길게 작성하는 지루한 일이 될 것이다.
더 극명하게 이해할 수 있는 예를 들어보자. 아래 코드가 EasyMock의 방식이고
mockFoo.bar(arg);
ctrl.setReturnValue(1);
ctrl.replay();
아래가 jMock의 방식이다.
mock.expects(once()).method("bar").with(same(arg)).will(returnValue(1));
가독성(readability) 관점에서 평가는 상반될 수 있는 극명한 차이를 보인다. 마치 초보자도 쉽게 사용할 수 있는 단순하고 직관적인 UI(User Interface)와 한번에 모든 것을 처리할 수 있는 단축키가 풍부한 UI 중에 무엇이 좋으냐를 고르는 것 같은 기분이다. :)
사용자 인터페이스나 프로그래밍 인터페이스나 다음의 상충 관계의 균형을 고려하는 것은 동일하게 적용할 수 있을 것 같다:
낮은 학습 비용 vs 업무(프로그래밍)의 생산성
이올린에 북마크하기
이올린에 추천하기