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)를 주입 받자.