1.
김아름
18.11.03 FEConf 2018
프 론 트 엔 드
프 로 젝 트 의
?
작 성 경 험 기
테스트코드

2.
반갑습니다.
저는김아름입니다.
퍼블리싱 위주의
업무에서 벗어나
프론트엔드 개발자로
일하고 싶어 퇴사.
코드스쿼드라는 곳에서
즐겁게 개발 공부를 한 뒤,
요즘은 열심히
구직활동중!

3.
지난 8월 말,
테스트코드를 처음 작성해보며 느꼈던 경험들을
개인 블로그에 적어 올린 것이 공유됨 + 발표제안

4.
ㅠ_ㅠ

5.
오늘 발표는 🙂
기존 프로젝트의 구현코드를 바탕으로
유닛 테스트를 처음 작성해보면서 느꼈던 경험들을 공유하려고 합니다.
(TDD 아님!)

6.
테스트에 관한 많은 자료들은 추상적이어서 잘 와닿지 않고,
실제로 작성하려 할 때 막막한 경우가 많은 것 같습니다.

7.
저는 테스트 숙련자가 아니지만,
저와 비슷한 위치에서 테스트에 입문하시려는 분들께
어떻게 테스트에 입문하고 코드를 작성했는지에 대해
구체적인 경험을 공유하면
의미있는 시간이 될 거라고 생각했어요.

8.
오늘 제가 드릴 얘기들이 정답이 아닐 수 있지만
더 좋은 방향을 고민하면서 같이 생각해보는 시간이 된다면 좋겠습니다.

9.
1. 테스트코드, 이론과 실행의 거리감 좁히기
2. 테스트코드, 이런 순서로 작성해 봤어요
3. 느낀 점과 남은 고민들
Content

10.
1
테스트코드,
이론과 실행의
거리감 좁히기.

11.
아니그런데잠깐...
테스트코드는어쩌다가(?) 시작했어요?

12.
아니그런데잠깐...
테스트코드는어쩌다가(?) 시작했어요?
솔직하게 말하면....

13.
첫시도는실패.
+

14.
+
첫시도는실패.

15.
뭔 소린지 모르겠는 이유.
생소한 용어가 너무 많이 나옴.
라이브러리 가이드, 검색한 글들도
이 용어들의 이해를 전제하에 설명됨.
SW테스트 분야에서
통용되는 용어가 있었구나.
이것부터 알고 가자.

16.
테스트의세계를이해하기

17.
테스트의전반적인이해는책으로...
(거의 유일한)
자바스크립트 테스트 책
• 테스트 세계의 전반적인 감잡기
• 주요 키워드를 파악

18.
책은QUnit,테스트는 Mocha
의외의 이득 🙊
다른 프레임워크이나
유사한 구성
하나만 잘 익히면
다른 테스트 프레임워크들의
파악도 쉽겠다!

19.
테스트의세계
• Unit Test VS TDD
• 테스트의 레벨에 따른 종류
• 유닛 테스트=단위 테스트(unit test)
• 통합 테스트(integration test)
• E2E 테스트

20.
테스트코드작성도구들
• test framework
• hook method
• 테스트 케이스 (test case)
• 명세
• given, when, then
• 테스트 더블 (test double)
• spy, stub
• 단언문 (assertion)
• 테스트 커버리지 (test coverage)

21.
테스트세계의이해를 바탕으로
+
작은테스트경험을
만들어보자

22.
명세
given, when, then 패턴
단언문(assertion)
helpers.js
독립적인 유틸함수를
모아놓은 파일
테스트 난이도 下

23.
작은테스트경험
• 테스트 작성의 감이 잡힘
• given, when, then을 나누어 작성하는 감
• 테스트코드 작성을 위한 도구들이 익숙해짐
• 파생되는 생각
• 구현코드의 내부로직을 보지 않고도 속성/메서드명으로 테스트코드가
잘 읽혀야 하겠네.
• 그래서 개발이 아니라 코드를 작성한다는 표현을 많이 쓰는 구나.
• 규모있는 프로젝트에서는 수많은 테스트케이스를 어떻게 관리할까?

24.
테스트세계의이해를 바탕으로
+
작은테스트경험을만들어서
=
경험을기반으로
더복잡한테스트를
고민할수 있는힘이 생겼다!

25.
2
테스트코드,
이런 순서로
작성해 봤어요.

26.
테스트코드작성할타겟선정
자동완성검색UI컴포넌트
class AutoCompleteSearcher
-
검색어를 입력하면,
검색 API에 요청을 날려
JSON응답데이터를 받음.
클라이언트 렌더링을 통해
결과목록을 그려줌

27.
작은테스트코드를 경험해봤지만,

28.
작은테스트코드를 경험해봤지만,
실제로테스트할 코드는
더크고 복잡한데
참고할것이 없을까?

29.
0.벤치마킹할테스트코드선정!
• 실제로쓰이는테스트코드를벤치마킹
• 오픈소스에는테스트코드가 있다는점
• 내프로젝트와비슷한객체로구성된오픈소스프로젝트
🧐

30.
벤치마킹코드에서
가장먼저눈에 띈것
유사한테스트케이스를
일관성있는구조로 묶어관리

31.
생각한 구조
최대한 3뎁스 (가독성)
1. 대제목(객체명)
2. 소제목(# 분류)
3. 테스트케이스
1.시각적/기능적으로읽기쉬운구조로테스트그룹짓기

32.
1.시각적/기능적으로읽기쉬운구조로테스트그룹짓기

33.
1.시각적/기능적으로읽기쉬운구조로테스트그룹짓기

34.
helpers.js
독립적인 함수들을 모아놓은 객체
함수명으로 분류
AutoCompleteSearcher.js
UI Component 객체
유사한 책임을 가진 메서드끼리 분류
# Create (Instance 생성 테스트)
# Initialize (Instance 초기화)
# Storage
# Request
# Rendering
# UI
# Event
2.소제목은‘#분류명’으로,분류기준은유사한성격끼리

35.
이런구조를만들어두면,
테스트에러발생시
어디서무엇을고쳐야하는지
빠르게파악할수있어좋겠구나.
가독성,유지보수에좋은 구조

36.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기

37.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
검색결과 목록이 있을 때라는 전제상황을 가진 그룹
검색결과 목록을 렌더링 -> 검색결과 목록 열기

38.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
검색결과 목록이 있을 때라는 전제상황을 가진 그룹
유사한 성격으로 묶은 그룹
(describe, context)
테스트케이스의
사전조건(given)이 중복

39.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
벤치마킹 코드에서 봤던 Hook 함수...?!
이럴 때 쓰나보다!

40.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
Hooks
- before()
- beforeEach()
- afterEach()
- after()
이미지출처: https://blog.pixelingene.com/2016/08/unit-testing-on-any-ui-project

41.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
검색결과 목록을 렌더링 -> 검색결과 목록 열기

42.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
스코프(descripe, context)를 활용
같이 사용하는 변수도 뺄 수 있음

43.
3.같은 그룹(스코프)에서중복되는사전조건(given)없애기
그룹(스코프)구조를유지하며
테스트코드를작성
스코프를 활용해
Hook,공통변수를관리하도록개선
훨씬더읽기쉬운 테스트코드로변했다~

44.
이런식으로계속테스트코드를
평화롭게작성....하다가
큰고민거리가 생김. 😣

45.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
helpers.js
독립적인 유틸함수들
테스트가 간단

46.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
helpers.js
독립적인 유틸함수들
테스트가 간단
AutoCompleteSearcher.js
여러 추상화수준으로 나뉜
메서드끼리 호출되는 구조

47.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
helpers.js
독립적인 유틸함수들
테스트가 간단
AutoCompleteSearcher.js
여러 추상화수준으로 나뉜
메서드끼리 호출되는 구조
어떤 메서드 레벨에서
주도권을 쥐고 테스트를 해야 할까?

48.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
검색어를 입력하면, 결과목록이 나타난다.
onInputVisibleKey() { // 상위메서드
renderResultList(); // 하위메서드
openResultList();
}

49.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
상위 메서드의 테스트코드에서 : 하위 메서드가 호출되었는지 체크
하위 메서드의 테스트코드에서 : 진짜 로직 테스트
(X) 처음 전략: 추상화 수준으로 구분

50.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
문제점
1. 깨지기 쉬운 테스트가 된다.
2. 명세가 테스트코드로 번역되지 않는다.

51.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
문제점
1. 깨지기 쉬운 테스트가 된다.
2. 명세가 테스트코드로 번역되지 않는다.
🙆

52.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
문제점
1. 깨지기 쉬운 테스트가 된다.
2. 명세가 테스트코드로 번역되지 않는다.
🙆

53.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
문제점
1. 깨지기 쉬운 테스트가 된다.
2. 명세가 테스트코드로 번역되지 않는다.
🙆

54.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
문제점
1. 깨지기 쉬운 테스트가 된다.
2. 명세가 테스트코드로 번역되지 않는다.
🙅

55.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
(O) 최종 전략: 로직의 복잡한 정도로 판단
상위 메서드의 테스트코드에서 하위 메서드의
• 호출여부를 체크 (X)
• 최종결과를 체크 (O)
renderResultList()의 결과 : 결과목록DOM 갯수 = 응답데이터 배열 길이
openResultList()의 결과 : 결과목록Wrapper의 className

56.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
이때 하위메서드의 로직이 복잡하면
하위메서드의 상세한 테스트를 별도 작성
renderResultList()의 결과 : 결과목록DOM 갯수 = 응답데이터 배열 길이
openResultList()의 결과 : 결과목록Wrapper의 className
(O) 최종 전략: 로직의 복잡한 정도로 판단

57.
4.추상화수준이다른메서드간테스트는어떻게해야할까?
🙆
목적에 맞는 테스트로 변함
명세가 테스트코드로 자연스럽게 읽힘
이전보다 좀 더 좋은 테스트코드가 된 것 같다..!
(O) 최종 전략: 로직의 복잡한 정도로 판단

58.
참고로,
테스트의명세- 스토리로 작성
테스트코드-구현코드의속성/함수명으로번역
가끔부자연스럽게읽히는 부분이생길때

59.
가끔부자연스럽게읽히는 부분이생길때
원인:구현코드의구린내(?)
-속성/함수명이적절치않음
-함수가여러책임을가지고있어이름이모호
적절한이름으로 추상화되었나?
구현코드의품질을개선하게되는
리팩토링을유도해주기도 했음..!
👏
(테스트코드짱!)

60.
5.조건문이많으면,테스트케이스를나눠밀도있는테스트하기
잠깐, 이 부분은 아직 테스트를 안했는데?
테스트코드 작성완료!

61.
5.조건문이많으면,테스트케이스를나눠밀도있는테스트하기
구현
코드
테스트
코드

62.
구현
코드
테스트
코드
테스트케이스 1개당 하나의 상황
조건별로 작성
밀도있는 테스트
5.조건문이많으면,테스트케이스를나눠밀도있는테스트하기

63.
3
느낀 점과
남은 고민들

64.
느낀점 👏
내 코드의 품질을 올려주는 훌륭한 도구
자주하던 나쁜 개발습관을 파악가능.
테스트코드 작성을 통해
구현코드가 잘 이해되도록 자주 들여다보니 좋게 계속 다듬게 됨.

65.
느낀점 👏
좋은 테스트코드를 위한 경험적 지식
이론보다 이런 경험을 통해서 노하우를 누적해 놓을수록
좋은 테스트코드를 만들 수 있겠다고 생각

66.
남은고민들&다음 방향 🤔
실제 코드와의 의존성을 낮추는 방법에 대한 고민이 부족
어느 수준까지 꼼꼼히 테스트 해야할까?
모든 코드의 테스트 코드를 다 작성하는게 정말 좋을까?
테스트 커버리지, 통합테스트, e2e테스트, TDD

67.
남은고민들&다음 방향 🤔
실제 코드와의 의존성을 낮추는 방법에 대한 고민이 부족
어느 수준까지 꼼꼼히 테스트 해야할까?
모든 코드의 테스트 코드를 다 작성하는게 정말 좋을까?
테스트 커버리지, 통합테스트, e2e테스트, TDD

68.
남은고민들&다음 방향 🤔
실제 코드와의 의존성을 낮추는 방법에 대한 고민이 부족
어느 수준까지 꼼꼼히 테스트 해야할까?
모든 코드의 테스트 코드를 다 작성하는게 정말 좋을까?
테스트 커버리지, 통합테스트, e2e테스트, TDD

69.
kim.ah.rm@gmail.com
감사합니다.