B-2. 도메인 테스트와 UI 테스트 분리 — 테스트 파일을 나눠야 할까?

이렇게 읽어보세요: 선배 크루의 고민 → 토론 질문을 먼저 읽고 → AS-IS 코드를 직접 분석 → 리뷰어의 피드백으로 관점 확인 → 탐색 미션에서 PR 깊이 파기

선배 크루의 고민

“TDD만으로는 알 수 없는 오류가 있다는 걸 느꼈습니다. 단위 테스트는 통과하는데 실제 UI에서는 문제가 생기는 경우가 있어서, 어디까지 테스트해야 하는지 고민됩니다.” — 기린, PR #356

“unit test만으로는 부족하다고 느꼈습니다. 컨트롤러를 통해 도메인 객체들이 연결되면서 생기는 문제를 잡으려면 통합 테스트가 필요한 것 같은데, 어떻게 구성해야 할지 모르겠습니다.” — 쿠마, PR #200

“함수가 하나의 기능만 하는지 판단하는 기준이 애매합니다. 테스트를 작성하다 보면 하나의 함수에 여러 검증이 필요한 경우가 많은데, 이게 함수 분리의 신호인지 궁금합니다.” — 기린, PR #356

이 코드를 보면서 이야기해봅시다

“이 buyLotto()를 테스트하려면 무엇을 준비해야 하나요? (DOM, validator, lottoMachine, ui) 이 중 도메인 로직만 테스트하고 싶다면?”
“이 함수에서 this.#lottoMachine.buyLotto(+moneyInput) 한 줄만 테스트하고 싶다면, 나머지 코드(DOM 접근, UI 렌더링)가 왜 방해가 되나요?”

AS-IS 코드

이렇게 한 곳에 모인 코드는, 테스트도 한 파일에 몰리게 됩니다.

출처: PR #234 — 부엉이 (2023, 2단계) · 해당 파일


// controller/stepTwo/WebLottoController.js — 컨트롤러가 DOM 접근 + 검증 + 도메인 로직 + UI 렌더링을 모두 수행
buyLotto() {
  try {
    ui.hideMoneyValidationText();
    const moneyInput = domList.moneyInput.value; // 컨트롤러가 DOM에 직접 접근
    inputValidator.validateMoneyInput(moneyInput);
    this.#lottoMachine.buyLotto(+moneyInput);
    ui.showRestUI(this.#lottoMachine.lottos);     // UI 렌더링도 여기서
  } catch (error) {
    // ...
  }
}
 
bindAllEvents() {
  // 컨트롤러가 DOM 요소를 직접 알고 이벤트를 바인딩
  this.addEvent({ element: ui.getDomWithName('buyBtn'), event: () => this.buyLotto(), type: 'click' });
  this.addEvent({ element: ui.getDomWithName('resultBtn'), event: () => this.calculateStatistics(), type: 'click' });
  this.addEvent({ element: ui.getDomWithName('retryBtn'), event: () => this.restartGame(), type: 'click' });
}

리뷰어의 피드백

“기능 테스트와 UI 테스트의 파일을 분리해보는 건 어떨까요~? 파일 하나에 있으니 찾기 어려워 지는 것 같아요!” — PR #44 (링크 )

“현재 step2-index.js파일에서 너무 많은 정보를 알고 있어야하고 이는 곧 변경에 취약한 설계라는 것을 의미합니다. 적절하게 도메인과 UI 객체를 분리해서 객체에게 메세지를 보내는 형식으로 변경해 보는 것은 어떨까요?” — PR #395 (링크 )

“Controller의 역할에 대해 다시한번 생각할 필요가 있을 것 같아요. 현재는 입력검증, 로직처리, 흐름제어등을 모두 직접적으로 하고 있기 때문에 Controller가 간단한 로직임에도 불구하고 많이 무거워진 상태입니다. Controller가 세부로직들을 모두 알 필요가 있을까요?” — PR #356 (링크 )