2. 모듈패턴으로 기존 코드 개선하기 - 견고한 JS 소프트웨어 만들기 | 김정환
클릭 카운터 모듈 (ClickCounter)
: 카운터 데이터를 다루는 모듈 (전역 공간에 있는 counter 변수를 ClickCounter 안에서 관리하자)
첫번째 스펙
"ClickCounter 모듈의 getValue() 는 카운터 값을 반환한다."
> git checkout --force ClickCounter-spec-1
두번째 스펙
"ClickCounter 모듈의 increase() 는 카운터 값을 1만큼 증가한다."
> git checkout --force ClickCounter-spec-2
beforEach는 it 함수 호출 직전에 실행되는 자스민 함수.
describe(() => {
beforeEach(() => {}) // 1
afterEach(() => {}) // 3
it(() => {}) // 2
})중복 코드를 beforeEach로 옮기자.
※ 중복 코드를 제거한 코드를 DRY(Don't Repeat Yourself) 하다.
클릭 카운트 뷰 모듈 (ClickCounte View)
카운터 데이터는 돔(DOM)에 반영되어야 한다. 데이터를 출력하고 이벤트 핸들러를 바인딩하는 일을 담당할 것이다.
첫번째 스펙
"ClickCounterView 모듈의 updateView()는 카운트 값을 출력한다."
> git checkout --force ClickCountView-spec-1
Q) 데이터를 조회할 ClickCounter를 어떻게 얻을까? 데이터를 출력할 돔 엘리먼트는 어떻게 테스트 할까?
A) 주입하자
- ClickCounter는 객체를 만들어 파라미터로 전달 받자
- 데이터를 출력할 돔 엘리먼트를 만들어 전달 받자
TDD 방식으로 사고하다 보면 이런 식으로 필요한 모듈을 주입받아 사용하는 경향이 생김
하나의 기능 단위로 모듈을 분리할 수 있기 때문에 단일 책임 원칙을 지킬 수 있다.
Q) ClickCountView에 의존성 주입이 되었는지는 어떻게 체크할까?
A) 의존성 주입을 테스트하는 코드를 작성한다.
두번째 스펙
"ClickCounterView 모듈의 increaseAndUpdateView()는 카운트 값을 증가하고 그 값을 출력한다."
> git checkout --force ClickCountView-spec-2
# 테스트 더블
단위 테스트 패턴으로, 테스트하기 곤란한 컴포넌트를 대체하여 테스트하는 것. 특정한 동작을 흉내만 낼뿐이지만 테스트 하기에는 적합하다.
- 더미(dummy): 인자를 채우기 위해 사용
- 스텁(sturb): 더미를 개선하여 실제 동작하게끔 만든 것. 리턴값을 하드코딩한다.
- 스파이(spy): 스텁과 유사, 내부적으로 기록을 남기는 추가 기능
- 페이크(fake): 스텁에서 발전한 실제 코드.
- 목(mock): 더미, 스텁, 스파이를 혼합한 형태
자스민에서는 테스트 더블을 스파이스(spies)라고 부른다. spyOn(), createSpy() 함수를 사용할 수 있다.
세번째 스펙
"클릭 이벤트가 발생하면 increaseAndUpdateView()를 실행한다."
> git checkout --force ClickCountView-spec-3
클릭 이벤트 핸들러(increseAndUpdateView)를 바인딩할 돔 엘리먼트(triggerEl)를 주입 받자.