Portfolio

들어가며

앞의 프레젠터는 앞의 시나리오에서 viewmodel을 로드할 때 사용자에게 보이기 적절한 형식으로 변환하는 것을 말한다. 또한 프레젠터는 험블 객체 패턴을 따른 형태이며 아키텍처 경계를 식별하고 보호하는 데 도움이된다.

험블 : 대강 만든 객체?

험블 객체 패턴

이는 디자인 패턴이며, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법을 고안한 것이다. 가장 기본적인 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. 나머지 모듈에는 험블 객체에 속하지 않은, 테스트하기 쉬운 행위를 모두 옮긴다.

예) GUI 단위 테스트를 할때 험블 객체 패턴을 사용하면 행위를 분리하여 프레젠터와 뷰라는 두 분류의 서로 다른 클래스로 만들어 테스트를 진행할 수 있다.

프레젠터와 뷰

뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지 않아 험블 객체로 분류되고 테스트하기가 어렵다.

반면에 프레젠터는 애플리케이션에서 데이터를 받아 화면에 표현하는 포맷으로 만드는 것으로테스트 하기 쉬운 객체로 분류된다. 이 역할을 통해 뷰는 데이터를 화면에 전달하는 역할을 하게 된다.

테스트와 아키텍처

험블 객체 패턴은 테스트 용이성에 있어서 좋은 예시가 된다. 그 이유는 행위를 테스트하기 쉬운 부분과 테스트하기 어려운 부분으로 분리하게 되고 이로 인해 아키텍처 경계가 정의 되기 때문이다.

위에서 프레젠터와 뷰를 나누어 그 사이에 경계가 존재하게 되며, 이 이외에도 수많은 경계가 존재한다.

데이터베이스 게이트웨이

유스케이스 인터랙터와 데이터베이스 사이에 데이터베이스 게이트웨이가 위치한다. 이 게이트웨이는 다형적인 인터페이스로 CRUD 작업관련 메서드를 포함한다.

유스케이스 계층에서는 SQL을 허용하지 않는다. 즉 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출하는 것이다. 그리고 인터페이스의 구현체는 데이터베이스 계층에 위치하게 된다.

⇒ DataAccessInterface와 DataAccess구현체가 같은 계층에 존재하는 줄 알았다.

이 구현체는 험블 객체가 된다. 반면에 인터랙터는 애플리케이션에 특화된 업무 규칙을 캡슐화하기 때문에 험블 객체가 아니다. 따라서 테스트하기 쉽지만, 게이트웨이는 스텁이나 테스트 더블로 적당히 교체할 수 있다.

⇒ 여기까지 말하는 단위 테스트가 행위 테스트가 되는 걸까요??

예로 들어서 mockito??

데이터 매퍼

데이터베이스로 돌아와서 그럼 ORM은 어느 계층에 속하는 가?

ORM은 존재하지 않는다. 이유는 객체는 데이터 구조가 아니기 때문이다. 사용자는 public을 통해 볼수 있지만 데이터는 private로 선언되어 사용자가 볼 수 없다.

사용자 관점에서 객체는 오퍼레이션 집합이다.

데이터 구조는 public 데이터 변수의 집합이다. ORM이라기 보다는 데이터 매퍼라 부르는 편이 나아보인다. 이 이유는 관계형 DB 테이블에서 가져온 데이터를 데이터 구조에 맞게 담아주기 때문이다.

즉 ORM은 데이터베이스 계층에 속하지만 게이트웨이 인터페이스와 데이터베이스 사이의 또 다른 험블 객체 경계를 형성하게 된다.

서비스 리스너

애플리케이션에서 일련의 서비스를 제공해야 한다면, 서비스 경계를 생성하는 험블 객체 패턴을 발견할 수 있을 까?

⇒ 서비스는 유스케이스와 같은 계층일까?

외부로부터 데이터를 받는 경우 서비스 리스너가 서비스 인터페이스로부터 데이터를 수신하고, 데이터를 애플리케이션에서 사용할 수 있게 간단한 데이터 구조로 포맷을 변경한다. 그런 후 이 데이터 구조는 서비스 경계를 가로질러서 내부로 전달된다.

결론

각 경계마다 험블 객체 패턴이 존재할 수 있다. 경계를 넘어가는 통신은 간단한 데이터 구조로 전달될 때가 많고, 그 경계는 테스트하기 어려운, 쉬운 두 분류로 분리될 수 있다.

⇒ 그래서 험블 객체 패턴을 이용하면 행위 테스트(mock)가 아닌 상태 테스트로 진행해야하나??

⇒ 아니면 험블 객체는 테스트를 진행하지 않는 것인가?

23 프레젠터와 험블 객체