[Java] Classic TDD vs Mockist TDD

얼마 전에 우테코에서 체스 피드백 2 강의를 들으면서, 디트로이트 학파 (classicist) vs 런던 학파 (Mockist)에 대해서 듣게 되었다. 둘 다 처음 들어본 용어여서 궁금한 마음에 이것저것 찾아보며 작성해보고자 한다. 

(전반적인 내용은 테코톡 발표 내용을 많이 참고하였습니다 🙇‍♀️)

---

✔️ 단위 테스트가 무엇일까?

단위 테스트는 다음과 같은 특징을 가져야 한다.

1. Low-level 테스트를 다루어야 한다.
2. 일반적인 테스트 도구를 사용해야 한다.
3. 빨라야 한다.

 

여기서 단위란 무엇일까?

만약, 기능 단위라고 구성된다면 객체지향의 관점에서는 해당 기능을 구현하는 클래스의 집합이 단위가 될 수도 있다.

 

우리는 이러한 단위 테스트를 진행하기 위해서, 어떠한 단위가 상호 작용할 수 있는 실제 객체를 사용하거나, test double을 활용할 수 있다. 단위 테스트는 크게 2가지의 유형으로 나뉘는데, 이는 아래와 같다.

https://www.xenonstack.com/blog/microservices-testing

1. Sociable Test

: 이는 어떠한 단위의 '행위'를 테스트하는데 중점을 둔다. 인터페이스 등을 활용하여 직접적으로 테스트를 진행할 수 있다.

test double을 사용하지 않고 상위 모듈을 통해서 하위 모듈을 직접적으로 테스트한다.

 

2. Solitary Test

: 어떠한 단위의 행위가 다른 행위와 종속되어 있다면, 최대한 독립적으로 가져가서 테스트를 진행하는 것이다.

이때, 독립적으로 가져가기 위해 다른 행위에 대해서 test double을 사용하곤 한다.

 

흔히 서비스 계층에 대해서 테스트를 할 때, 다양한 서비스 계층이 엮여 있으면 기능 단위로 테스트를 하더라도 다른 서비스 계층의 기능까지 함께 테스트를 하면서 일종의 통합 테스트처럼 느껴질 수 있다.

 

sociable test를 지향하는 사람들을 classicist, solitary test를 지향하는 사람들을 mockist라고 부른다.

---

✔️ 용어 정리

시작하기 앞서, 테스트 패턴에서 사용하는 용어들에 대해 간략하게 정리하고 가자.

 

💬 SUT

: System Under Test, 테스트 대상 시스템으로 일종의 테스트를 하려는 대상을 의미한다.

세부적으로 AUT (application Under Test), MUT (Method Under Test), CUT (Class Under Test), OUT (Object Under Test) 등으로 나뉘기도 한다.

 

💬 협력 객체

SUT가 의존하는 클래스로, SUT와 연관관계를 가지고 있는 클래스를 의미한다.

 

---

 

✔️ Test Double

https://tecoble.techcourse.co.kr/post/2020-09-19-what-is-test-double/

 

실제 객체의 행위가 테스트하기 어렵거나 비용이 많이 들 때 사용하는 가짜 객체이다.

대표적으로는 Dummy, Fake, Mock, Spy, Stub 등이 존재한다.

 

각각에 대해 간단하게 설명해보자면 다음과 같다. 간단한 예시를 들기 위해서 다음과 같은 코드가 있다고 가정해보자.

import java.util.Optional;

public interface UserDao {
    Optional<UserEntity> findByName(final String name);

    Long save(final String name);
}

// UserEntity
public final class UserEntity {
    private Long id;
    private final String name;

    public UserEntity(final Long id, final String name) {
        this.id = id;
        this.name = name;
    }
}

이번 체스 미션에서 사용했던 코드로, 사용자의 이름을 바탕으로 조회하는 기능과 저장하는 기능이 담겨있다.

위의 코드는 실제 프로덕션 코드에서는 다음과 같이 구현되어 있다.

public final class UserDaoImpl implements UserDao {

    private final JdbcTemplate jdbcTemplate;

    public UserDaoImpl(final JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public Optional<UserEntity> findByName(final String name) {
        final String query = "SELECT * FROM user WHERE user_name = ?";
        return jdbcTemplate.findOne(query, (resultSet -> new UserEntity(
                resultSet.getLong("user_id"),
                resultSet.getString("user_name"))
        ), name);
    }

    @Override
    public Long save(final String name) {
        final String query = "INSERT INTO user(user_name) VALUES(?)";
        return jdbcTemplate.executeUpdate(query, name);
    }
}

 

이 코드를 각각의 테스트 더블로 적용해보자.

 

1. 스텁 (Stub)

- 호출이 되었을 때 미리 정해진 결과를 반환하는 객체이다.

public class MockUserDao implements UserDao {
    @Override
    public Optional<UserEntity> findByName(final String name) {
        return Optional.of(new UserEntity(1L, "journey"));
    }

    @Override
    public Long save(final String name) {
        return 1L;
    }
}

위와 같이, 해당 메서드를 반환하면 항상 같은 결과를 반환하도록 하는 것이다.

 

 

2. 페이크 (Fake)

- 실제로 동작하지만, 조금 더 가벼운 버전의 구현을 사용하여 테스트의 속도를 높이는 방법이다.

public class MockUserDao implements UserDao {
    private final Map<Long, UserEntity> STORAGE = new ConcurrentHashMap<>();
    private final AtomicLong pk = new AtomicLong(0L);

    @Override
    public Optional<UserEntity> findByName(final String name) {
        return STORAGE.entrySet().stream()
                .filter(entry -> entry.getValue().getName().equals(name))
                .map(entry -> new UserEntity(entry.getKey(), entry.getValue().getName()))
                .findFirst();
    }

    @Override
    public Long save(final String name) {
        STORAGE.put(pk.addAndGet(1L), new UserEntity(name));
        return pk.longValue();
    }
}

실제로 나는 이번 체스 미션에서 위와 같은 방식으로 구현하였다.

ConcurrentHashMap 객체를 일종의 DB 스토리지로 사용하여서 실제로 값을 삽입하고, 조회하는 기능이 동작하도록 만들었다.

 

 

3. 스파이 (Spy)

- Stub의 역할을 가지면서, 호출된 함수의 정보를 기록하여 나중에 테스트에서 사용할 수 있는 객체를 의미한다.

public class MockUserDao implements UserDao {
    private final List<String> queries = new ArrayList<>();

    @Override
    public Optional<UserEntity> findByName(final String name) {
        queries.add("findByName");
        return Optional.of(new UserEntity(1L, "journey"));
    }

    @Override
    public Long save(final String name) {
        queries.add("save");
        return 1L;
    }

    public boolean isCall(final String query) {
        return queries.contains(query);
    }
}

내가 이해한 바로는 이런 식으로 Stub의 기능에 어떤 식으로 호출되었는지에 대한 정보도 포함하는 것이라고 생각했다.

그래서 나중에 외부적으로 isCall을 통해서 해당 메서드가 호출되었는지 확인할 수 있도록 하는 게 아닐까 싶다.

 

 

4. 더미 (Dummy) 

- 단지 인스턴스화된 객체가 필요하면서, 해당 객체의 기능은 필요없이 실제로 사용되지 않을 경우 사용한다.

위의 예제 코드보다는 다른 경우가 더 적합할 것 같아서, 예제를 바꾸어보았다.

public class MockUserDao {
    public void printUserInfo() {
        // nothing.
    }
}

이런 식으로 단순히 printUserInfo()를 호출했다는 것만 필요할 때 사용한다.

개인적인 생각으로는, 외부 api에 대해서 호출을 해야 하는 경우 (ex. 알림 전송 같이 반환값은 필요 없는 경우)나 복잡한 ui 로직이 필요하다면 더미를 활용할 수 있을 것으로 판단된다.

 

 

5. 목 (Mock)

호출에 대해서 어떤 것을 호출하고 어떤 것을 반환할지 미리 지정하는 것이다.

대표적으로 Mockito 프레임워크가 존재한다. 이 역시 라이브러리를 사용한다면 다음과 같이 구현할 수 있다.

UserDao userDao = mock(UserDao.class);

// 무엇을 호출하면 어떤 식으로 반환할지 미리 정의
        when(userDao.findByName(any())).thenReturn(new UserEntity(1L, "journey"));
        when(userDao.save(any())).thenReturn(1L);

 

흔히 다음과 같이 나누어진다고도 한다. (어려운 내용이니 우선은 그냥 읽고 넘어가자!)

이름	목적	동작이 있나?	SUT에 간접 입력 주입	SUT 간접 출력 처리	테스트가 제공하는 값
Stub	SUT의 간접 입력 검증	있음	함	무시	입력값
Fake	빠른 실행	있음	없음	간접 출력 사용	없음
Spy	SUT의 간접 출력 검증	있음	선택 사항	나중에 검증하려고 함	입력 (선택 사항)
Dummy	속성이나 메서드 인자로서 작동	없음	안 함	안 함	없음
Mock	SUT의 간접 출력 검증	있음	선택 사항	기대값과 비교하여 정확한지 검증함	입력, 기대 출력

 

 

---

✔️ Classicist - 상태 검증 / Mockist - 행위 검증

classicist에서는 주로 검증을 하기 위해서 어떠한 상황을 수행한 다음, 해당 객체의 내부 상태를 확인하게 된다.

이때, 행위가 수행된 다음 어떠한 상태인지 확인하기 위해서 getter 같은 메서드 등이 추가될 수 있다.

위에서 말했던 'stub'의 경우 상태 검증의 일부라고 볼 수 있다.

public class CrewServiceTest {

    private CrewService crewService;
    private CrewRepository crewRepository;

    @Before
    public void setUp() {
        crewRepository = mock(CrewRepository.class);
        crewService = new CrewService(crewRepository);
    }

    @Test
    public void createCrew() {
        // given
        Crew crew = new Crew("journey");

        // when
        crewRepository.createCrew(crew);

        // then
        Crew createdCrew = crewRepository.findByName("journey");
        assertThat(createdCrew.getName()).isEqualTo("journey");
    }
}

createCrew()를 통해서 해당 크루가 잘 생성되었는지 테스트 하는 코드이다.

crew를 삽입한 다음, 크루의 이름을 통해서 해당 크루를 찾은 다음 getName()을 통해서 우리가 생성한 크루인지 확인할 수 있다.

이런 식으로 해당 크루를 삽입한 뒤, 내부의 객체가 잘 생성되었는지 상태를 확인하는 것이다.

 

반면에 Mockist의 경우 특정한 동작을 수행하는지 확인하는 검증 방법이다.

위에서 말했던 'mock'의 경우 행위 검증의 일부라고 볼 수 있다.

public class CrewServiceTest {

    private CrewService crewService;
    private CrewRepository crewRepository;

    @Before
    public void setUp() {
        crewRepository = mock(CrewRepository.class);
        crewService = new CrewService(crewRepository);
    }

    @Test
    public void createCrew() {
        // given
        Crew crew = new Crew("journey");
        given(crewRepository.save(crew)).willReturn(crew);

        // when
        crewRepository.createCrew(crew);

        // then
        verify(crewRepository).save(crew);
    }
}

위의 코드에서 CrewService는 CrewRepository를 의존하고 있는 형태이다. 

 

이때, 테스트 코드에서 Crew 객체를 생성하고, save 메서드를 호출하면 생성한 crew를 반환하도록 해보자.

이때, verify를 통해서 crew 객체와 함께 해당 save 메서드가 호출되었는지 확인한다. 

save() 메서드의 호출에 대한 테스트를 진행했다고도 볼 수 있으며, 만약 위의 테스트가 실패했다면 save() 메서드를 호출하지 않았거나, 인자로 넘긴 crew 객체가 잘못되었음을 뜻하게 된다.

 

이런 식으로 mockist를 사용하게 되면 getter 같이 상태를 받아올 메서드는 필요없지만, SUT에 대해 구현 방식이 노출된다는 단점이 있다.

 

---

✔️  각각의 장단점을 체크해보기

💬 문제 상황 1. 외부 API를 호출하는 경우

소셜 로그인 기능에 대해서 생각해보자.

사용자가 크루로서 추가되기 위해서는 사용자의 소셜 로그인 정보가 필요하며, 외부 api를 호출하는 작업이 필요하다.

그러나, 이러한 외부 api는 항상 동일한 결과가 나올 것이라고 기대할 수는 없으며, 비용이 비싸다.

(만약 외부 api 서버가 망가졌다면? 혹은, 내가 요청한 정보가 중간에 유실되었다면?)

 

그렇기 때문에, 매번 외부 api를 호출하여 테스트 하는 것은 별로 좋은 방법은 아니다.

이런 경우에서는 mockist가 더 좋다고 볼 수 있다. 외부 api를 호출하는 경우에는 단순히 예측을 해주면 되는 것이다.

@Test
public void createCrew() {
        Crew crew = new Crew("journey");
        given(crewRepository.save(crew)).willReturn(crew);
        given(oauthService.getUserInfo(crew.getEmail()).willReturn(...); // here!

        crewRepository.createCrew(crew);

        verify(crewRepository).save(crew);
        verify(oauthService).getUserInfo(crew.getEmail());
        }

 

classicist는 이런 경우에 항상 외부 api를 호출할까?

그렇지는 않다. 테스트를 하기 어렵다면, test double의 종류에 종속되지 않고 다른 것을 활용하면 되는 것이다.

 

💬 문제 상황 2. 요구사항이 추가되었을 경우

다음과 같은 상황을 들 수도 있다.

만약 크루를 추가하기 전에, 내부적으로 MissionService를 통해서 해당 크루의 미션 현황에 대해 검증한다고 생각해보자.

@Test
public void createCrew() {
        // given
        Crew crew = new Crew("journey");

        // when
        crewRepository.createCrew(crew);

        // then
        Crew createdCrew = crewRepository.findByName("journey");
        assertThat(createdCrew.getName()).isEqualTo("journey");
        }

classicist의 경우 코드가 변경되지 않는다. 왜냐하면, 내부적으로 createCrew()에서 무슨 행위를 하든 테스트는 알지 못하기 때문이다. 그저 단순히 진행을 하였을 때 크루가 저장이 되고, 크루에 대한 정보를 불러오기만 하면 된다.

프로덕션의 코드 변화가 테스트 코드에 변화를 많이 끼치지 않기 때문에, 기능 추가가 원활해진다.

 

@Test
public void createCrew() {
        Crew crew = new Crew("journey");
        given(crewRepository.save(crew)).willReturn(crew);
        given(missionService.isAllMissionPass(crew.getEmail()).willReturn(...); // here!

        crewRepository.createCrew(crew);

        verify(crewRepository).save(crew);
        verify(missionService).isAllMissionPass(crew.getEmail()); // here!
        }

반면, mockist의 경우 코드의 변화가 생길 수밖에 없다.

왜냐하면, save에서 내부적으로 호출되는 행위에 대해서 명시적으로 테스트를 진행해주어야 하기 때문이다.

위와 같이 해당 메서드가 호출되었을 때 어떤 행위를 할지, 그리고 호출되었는지에 대한 테스트 코드를 작성해야 한다. 만약 TDD를 애용한다면 이런 변화에 계속 대응해야 하기 때문에 상당히 귀찮아질 수도 있다.

 

💬 문제 상황 3. 버그가 발생할 경우

만약, 위의 상황에서 갑자기 MissionService에 장애가 발생했다고 생각해보자. 

이렇게 되면 classicist로 구현한 코드는 내부적으로 장애가 발생하면서 해당 테스트까지 실패하게 될 것이다.

즉, 테스트가 격리되지 않고 외부에서 내부 요소들까지 함께 테스트 하면서 장애가 전파되는 것이다.

 

만약 MissionService가 CrewService뿐만 아니라 PrologService, JjimggongService에도 연관이 있다고 가정해보자.

이렇게 되면 다음과 같이 오류가 모두에 전파된다.

하지만, mockist는 단순히 버그가 발생한 클래스에 대해서만 실패하게 된다.

테스트 코드 상으로 내부 로직은 모두 실제 호출이 아닌, 어떤 식으로 호출될 것인지 제어를 하기 때문에 영향이 없는 것이다.

하지만, classicist는 이런 오류 전파에 크게 신경쓰지 않는다.

어차피 TDD를 진행하게 된다면 작은 단위 테스트부터 시작하여 통합 테스트까지, 계속해서 전체 테스트 코드를 돌리게 될 것이고, 그러면 테스트를 돌릴 때 마지막으로 수정한 파일이 오류가 발생된 지점임을 쉽게 파악할 수 있기 때문에 큰 문제가 되지 않는다고 말한다.

 

 

💬 문제 상황 4. 세부 요소는 잘 되는데, 통합 테스트는 안 될 때

만약, CrewService에서 canGraduate() 메서드가 다음과 같이 실행된다고 가정해보자.

크루들의 수료 여부를 판단하기 위해서 PrologService에서 글을 작성하였는지, JjimggongService에서 예약을 한 적 있는지, MissionService에서 모든 미션을 통과했는지 판단하는 로직을 호출한다.

classicist는 다음과 같은 플로우로 진행한다.

💬 CrewService에서 졸업 가능 여부를 판단하는 테스트가 필요해!

1. PrologService에서 글 작성 여부 판단 메서드 생성
2. JjimggonService에서 예약 여부 판단 메서드 생성 
3. MissionService에서 모든 미션 통과 여부 판단 메서드 생성 
4. CrewService에서 테스트 진행!

하지만, classicist는 당장 테스트를 진행하고 있는 CrewService의 canGraduate() 메서드의 테스트에만 집중하고 있었을 것이다. 그렇기 때문에 중간에 테스트 코드를 작성하지 않았거나, 혹은 제대로 확인하지 못했다면 오류가 발생하더라도 넘어갔을 수도 있다.

즉, classicist에서는 이러한 협력 객체에 대해서는 꼼꼼한 테스트가 필요하다.

 

반면에, mockist는 다음과 같이 진행한다.

1. PrologService에서 글 작성 여부 판단 메서드에 대한 mock 객체 생성
2. JjimggonService에서 예약 여부 판단 메서드에 대한 mock 객체 생성
3. MissionService에서 모든 미션 통과 여부 판단 mock 객체 생성
4. CrewService에서 테스트 완료! 
5. 각각에 대한 세부 구현 진행

협력 객체를 구현하기 전부터 mock 객체를 생성해두기 때문에 기본적으로 기능을 구현해야 하는 목록들에 대해 더 잘 인식하게 된다.

Mockist는 기본적으로 협력 객체를 구현하기 전에 SUT에 대한 테스트를 작성하지만, classicist는 SUT에 대한 기능을 모두 구현한 다음에 협력 객체에 대해 테스트를 진행하여 놓칠 확률이 높다는 것이다.

 

---

✔️ Inside-Out vs Outside-In

classicist는 inside-out을, mockist는 outside-in을 활용해서 개발을 진행한다.

전자는 하나의 기능을 구현할 때 내부 구성 요소들을 하나씩 구성해나가면서 (도메인부터 설계) 가장 마지막에 controller를 생성해 사용자에게 제공하는 방법이고, 후자는 UI와 가장 가까운 계층부터 시작하여 도메인까지 내려가는 방식이다.

 

Inside-out의 경우 어떤 도메인부터 시작하면 좋을지 갈피를 잡기 어려운 경우가 많다.

그러나, 리팩터링을 진행하면서 주로 객체에 대한 책임 분리를 진행할 때 보다 나은 도메인 모델이 도출될 수도 있고, 작은 요소부터 시작하기 때문에 오버 엔지니어링도 비교적 피할 수 있다. 또한, 내부 요소에 대한 구현을 위주로 진행하다 보니까 기능적으로 안정성을 보았을 때 초기에는 더 유리할 수도 있을 것 같다. 그러나, 협력 관계를 제대로 세우지 않으면 잘못된 테스트를 작성할 수도 있다는 것이 단점이다. (위에서 말했던 것처럼 빼먹는다든지... 그런 경우가 생길 수도 있으니까)

 

반면, Outside-in의 경우 협력 객체 자체가 구현되지 않은 상태에서 진행하기 때문에, 어떤 객체가 어떤 것을 의존하는지, 상호 작용을 어떤 식으로 하는지에 더 집중하게 된다. 사용자에게 가장 맞닿은 영역부터 진행하기 때문에 '사용자의 요청이 들어왔을 때, 무엇을 제공해야 하지?'라는 물음으로 시작하여, 내부 협력 객체의 구성에 대해서 고민하게 된다. 어차피 구현되지 않은 부분은 Mock으로 설계하면 되는 것이니까. 이 덕분에 객체의 세부 구현보다는 행위에 집중하게 되고, 책임에 대해 더 명확하게 나타낼 수 있어서 객체지향적인 코드 작성이 가능할 수 있다. 하지만 책임 분리에 익숙하지 않다면 오히려 오버 엔지니어링을 가질 수도 있다는 게 단점이다.

 

	classicist	mockist
테스트 단위	sociable test	solitary test
테스트 검증	상태 검증	행위 검증
협력 객체 준비	Fixture 구성 및 재사용	메서드마다 Mock 생성 및 기대값 설정
간단한 협력 객체	실제 객체 사용	테스트 더블 적극 사용
어려운 협력 객체	테스트 더블 사용 고려	테스트 더블 적극 사용
테스트 유지 보수	Fixture의 변경이 있을 때 테스트가 깨진다	구현 테스트로 이어져서 테스트 수정 시 많은 시간이 소요될 수 있다
테스트 격리	X (디버그가 힘들다)	O (통합 테스트 필요)
디자인 스타일	Inside-out	Outside-in

 

이 말을 듣고 일종의 DDD와 비슷한 것일까? 라는 생각도 했었는데,

생각해보면 DDD는 도메인 주도 개발이고, 우리가 말하는 classicist와 Mockist는 TDD - 즉, 테스트 주도 개발이다.

아예 다른 개발 방법론이지만, 만약 DDD를 진행하면서 테스트 코드를 작성하게 된다면 이는 classicist에 조금 더 가까운 형태가 아닐까 싶다. (도메인 테스트 -> 작성... 이런 느낌 아닐까?)

 

---

테스트 코드를 열심히 작성해야겠다... 끝!