험블 개체 패턴 | Steven Giesel

👓 읽을 거리
1

앞으로 짧은 글은 번역해서 올려 보도록 하겠습니다.

험블 개체 패턴은 다루기 쉬운 동작(도메인 로직)과 다루기 어려운 동작(외부 이벤트나 종속성 등)을 분리하는 것을 목표로 특히 단위 테스트를 더 쉽게 만들기 위한 디자인 패턴입니다.

이제 험블 개체 패턴이 무엇이며 어떻게 활용할 수 있는지 살펴보겠습니다.

험블 개체

프로그램을 작성할 때 컴퓨터의 다른 부분이나 데이터베이스나 인터넷 서비스 같은 외부 세계와 통신해야 하는 경우가 많습니다. 하지만 프로그램이 제대로 작동하는지 테스트하고 싶을 때 이러한 다른 부분과 통신하는 것이 어려울 수 있습니다.

이 문제를 해결하기 위해 험블 개체 패턴을 사용하여 컴퓨터의 다른 부분이나 외부 세계와 통신해야 하는 프로그램 부분과 그렇지 않은 프로그램 부분을 분리할 수 있습니다. 외부 세계와 통신할 필요가 없는 프로그램 부분은 다른 것들에 대한 걱정 없이 분리하여 테스트할 수 있으므로 테스트하기가 훨씬 쉽습니다.

쉬운 단계로: 테스트하기 어려운 부분을 꺼내서 테스트에서 스터브/모의 테스트할 수 있는 래퍼에 넣습니다. 이 래퍼를 험블 개체라고 합니다. 코드에 DateTime.UtcNow에 대한 종속성이 있는 경우가 있나요? 그렇다면 "지금"으로 무엇을 하느냐에 따라 안정적인 테스트를 하는 것이 정말 까다로울 수 있습니다. 따라서 해당 부분을 "추출"하여 래퍼에 넣으면 됩니다:

public interface IDateTimeProvider
{
  DateTime UtcNow { get; }
}

public class DateTimeProvider : IDateTimeProvider
{
  public DateTime UtcNow => DateTime.UtcNow;
}

public class MyService
{
  public MyService(IDateTimeProvider dateTimeProvider) { ... }
}

좋은 점은 테스트하기 어려운 항목과 테스트하기 쉬운 항목을 캡슐화했다는 점입니다. 그리고 이제 우리는 완전한 원점으로 돌아가고 있습니다: 테스트하기 어려운 항목은 이상적으로는 더 이상 테스트할 필요가 없습니다. 애초에 DateTime.UtcNow를 테스트하는 것은 좋은 생각이 아닙니다. 첫째, 애초에 테스트를 어떻게 설정하겠느냐는 점과 둘째, 내 코드가 아니기 때문입니다. DateTime.UtcNow는 여러분의 관점에서 볼 때 타사 코드이며, 타사 코드를 단위 테스트하지 마세요.

결론

험블 개체 패턴을 사용하면 특히 아키텍처의 경계에서 작업을 더 쉽게 수행할 수 있습니다. 시스템 시간의 예에서 살펴봤지만, 이 규칙을 네트워크를 통한 I/O 액세스나 다른 것에도 적용할 수 있습니다.

원문

4개의 좋아요