내 방은 매우 쉽게 어질러진다. 방 정리 중 테스트 코드와의 연관성이 떠올라서 글을 작성해본다.
재택 근무를 하던 중 팔굽혀펴기가 하고 싶어졌다. 방이 어질러져있다면 팔굽혀펴기를 하기 전에 방부터 치워야한다. 팔굽혀펴기 할 공간이 없기 때문이다. 방을 치우기 위해서는 이불을 개어야하고 빨래도 개어야 하고 이것저것 할 일이 많아져 결국 30분 동안 방 정리만 하게 되는 내 모습을 볼 수 있다. 이렇듯 방이 어질러지면 나의 활동이 매우 제한적이게 된다.
나는 팔굽혀펴기를 하고 싶었을 뿐인데 방이 어질러져 있다는 의존성을 해결해야만 진짜 목적인 팔굽혀펴기를 시작할 준비가 되는 상황이다.
테스트 코드도 마찬가지다. 아래와 같은 코드 조각을 살펴보자
class Given {
private final String testMe;
private final HugeDependency dependency;
}
class TestService {
public Actual when(Given given) {
return given.getTestMe();
}
]
@Test
public void test() {
// given
Given given = new Given("given", new HugeDependency(...));
// when
Actual actual = testService.when(given);
// then
assertThat(actual, is(expected));
}
TestService.when()
을 테스트 하는 코드이다. 테스트하는 메서드에서는 Given.testMe 만 필요한데, 테스트하기 위해서는 반드시 Given.HugeDependency
를 주입해줘야한다.
그런데 만약 HugeDependency에 필수 필드가 10개정도 된다면 어떨까? 테스트를 위해서 사용하지 않는 필드를 10개나 추가해줘야한다. 이런 의존성들이 테스트 작성을 불편하고 귀찮게 만든다. 이런 의존성들은 결국 테스트 코드 생략까지 이어질 수 있다. 마치 내가 방 정리가 귀찮아서 팔굽혀펴기를 생략하는 것 처럼.
항상 작게작게를 기억하자. 방정리를 바로바로 한다면 치워야할 것이 적어지고 방정리에 드는 시간이 줄어든다. 방이 항상 깨끗한 상태이면 언제 어디서 바로 엎드려서 팔을 굽혔다 폈다 할 수 있다.
테스트 코드도 마찬가지다. 위의 코드 조각에서는 Service 로직은 작게 유지하는 것에 성공 했으나 도메인 객체를 작게 유지하는데에 실패했다. 객체를 관심사에 맞게 분리하여 더 작게 유지하면 테스트하기 쉽고 읽기 쉬운 코드가 될 것이다.