1.
엔지니어의 학습,
그리고 테스트 코드
박미정
mjpark03@gmail.com

2.
SI SW
스타트업
프리랜서

3.
(첫 번째 주제)
엔지니어의 학습

4.
(경고)
너무나 당연한 이야기, 지루할 수 있습니다.

5.
엔지니어는 왜 공부해야 하는가?
(이상편: 엔지니어의 본능)

6.
엔지니어는 왜 공부해야 하는가?
● 기술 변화 속도 ● 성능 개선 욕구

7.
엔지니어는 왜 공부해야 하는가?
(현실편: 존경하는 지인 분들에게 물어봤습니다.)

8.
생계형 프로그래머이기 때문에 당장 먹고사는데 필요한 것을 공부해요.
먹고사는데 필요한 만큼 공부해요.
현실편: 1번 지인

9.
만들고 싶은게 많아요. 일단 만들고 싶은게 생기면,
그 과정에서 문제를 만나는 양과 공부의 양이 비례하는 것 같아요.
현실편: 2번 지인

10.
공통점이 보이시나요?

11.
공통점이 보이시나요?
● 동기 부여

12.
엔지니어는 어떻게 공부해야 하는가?

13.
엔지니어는 어떻게 공부해야 하는가?
● 문서 완독 유형
● 필요한 부분 습득 유형
● MOOC 유형
● 남 코드 보기 유형
● 사람 찬스 유형
● 토이 프로젝트 유형

14.
나의 공부 철칙

15.
나의 공부 철칙
● 절대적 시간 확보
● 우선 순위

16.
철칙: 절대적 시간 확보
Welcome to the 얼또

17.
철칙: 절대적 시간 확보

18.
철칙: 우선 순위
요즘 함수형 프로그래밍이 유행이라며?
서버 개발말고 다른 개발도 하고싶어, 앱 개발 공부해볼까?

19.
철칙: 우선 순위
새 회사에서는 Play Framework를 쓰네, 공부하자!
남 코드를 분석할 때 테스트 코드의 도움을 받았으니 제대로 공부해 보자!
2년 가까이 유지한 얼또를 서비스로 만들어보자, 이왕이면 React로?

20.
(두 번째 주제)
그리고 테스트 코드
두 번째 주제인 테스트 코드에 대한 이야기를 해볼까 해요

21.
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
테스트 코드 혹은 테스트 주도 개발에 대한 논쟁은 많죠

22.
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
경험이 미천하여 테스트 코드를 강요하려는 이야기는 아니에요

23.
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
다만, 제가 겪은 장점을 기반으로 설득시켜 보고자 해요

24.
Test-driven development (TDD) is a software development process that
relies on the repetition of a very short development cycle
테스트 주도 개발 (TDD)
출처: WIKIPEDIA Test-driven development
저는 테스트 코드에 대해 이야기한다고 했죠
테스트 주도 개발에 이야기하려는 건 아니에요

25.
Test-driven development (TDD) is a software development process that
relies on the repetition of a very short development cycle
테스트 주도 개발 (TDD)
출처: WIKIPEDIA Test-driven development
가볍게 테스트 주도 개발과 테스트 코드의 정의를 확인하고
구분해 보고자 해요

26.
Test-driven development (TDD) is a software development process that
relies on the repetition of a very short development cycle
테스트 주도 개발 (TDD)
출처: WIKIPEDIA Test-driven development
테스트 주도 개발은 소프트웨어 개발 프로세스 방법 중 하나에요

27.
Test-driven development (TDD) is a software development process that
relies on the repetition of a very short development cycle
테스트 주도 개발 (TDD)
출처: WIKIPEDIA Test-driven development
절대, 테스트 기법 중 하나가 아니에요
소프트웨어를 개발하는 프로세스 방법 중 하나이죠

28.
unit testing is a software testing method by which individual units of
source code, ... are tested to determine whether they are fit for use.
테스트 코드
출처: WIKIPEDIA Unit testing
그럼 테스트 코드의 정의를 살펴볼까요

29.
unit testing is a software testing method by which individual units of
source code, ... are tested to determine whether they are fit for use.
테스트 코드
출처: WIKIPEDIA Unit testing
유닛 테스트의 정의를 찾아봤어요

30.
unit testing is a software testing method by which individual units of
source code, ... are tested to determine whether they are fit for use.
테스트 코드
출처: WIKIPEDIA Unit testing
유닛 테스트는 소프트웨어 테스트 기법 중 하나이죠

31.
unit testing is a software testing method by which individual units of
source code, ... are tested to determine whether they are fit for use.
테스트 코드
출처: WIKIPEDIA Unit testing
테스트 주도 개발의 정의와는 다른 범주의 이야기에요

32.
테스트 코드만 이야기해 볼게요
다시 말씀 드리지만
저는 테스트 코드에 대해 이야기하려 해요

33.
왜 테스트 코드만 이야기 할까요?

34.
테스트 코드 작성이 첫 번째 단계
테스트 주도 개발을 검색하면 자주 볼 수 있는
테스트 주도 개발 사이클을 도식화한 그림이죠

35.
테스트 코드 작성이 첫 번째 단계
보시는 것 처럼 실패하는 테스트 코드를 작성하는 일이 첫 번째 단계에요

36.
테스트 코드 작성이 첫 번째 단계
만약 첫 번째 단계인 테스트 코드를 작성하는 일이
납득되지 않거나 익숙하지 않다면

37.
테스트 코드 작성이 첫 번째 단계
테스트 주도 개발을 이해하는 것도 불가능에 가깝겠죠

38.
테스트 코드 작성이 첫 번째 단계
사실 이건 두 번째 이유이고

39.
테스트 코드 작성이 첫 번째 단계
진짜 이유는
아직 테스트 주도 개발을 짧은 시간에 전달하기에는

40.
테스트 코드 작성이 첫 번째 단계
제 경험이 부족하네요 (땀)

41.
테스트 코드를 반대하는 사람들의 의견은?

42.
테스트 코드: 반대
프로덕트 코드보다 테스트 코드가 너무 길어져요

43.
테스트 코드: 반대
테스트 코드가 생각보다 많은 것을 해결하지 않아요

44.
테스트 코드: 반대
테스트 코드를 만들기 위한 너무 지식이 많이 필요해요

45.
테스트 코드를 찬성하는 사람들의 의견은?

46.
테스트 코드: 찬성
프로덕트 코드를 더 잘 이해하게 되요
프로덕트 코드보다 테스트 코드가 너무 길어져요

47.
테스트 코드: 찬성
테스트 코드는 적어도 최소한의 문제를 해결해요
테스트 코드가 생각보다 많은 것을 해결하지 않아요

48.
테스트 코드: 찬성
제대로 하기 위해 노력이 필요하지 않은 분야가 있나요?
테스트 코드를 만들기 위한 지식이 너무 많이 필요해요

49.
테스트 코드에 찬성하는 나의 실제 사례?
그럼 테스트 코드에 찬성하는
저의 실제 사례를 이야기해볼까 해요

50.
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.

51.
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)

52.
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)
어랏, 테스트 코드가 있네?

53.
테스트 코드: 나의 사례 1
@Test
public void getMessage_eventTypeIsIssueBodyChanged_returnXXX() {
NotificationEvent notificationEvent = getNotificationEvent(ResourceType.ISSUE_POST);
notificationEvent.eventType = EventType.ISSUE_BODY_CHANGED;
notificationEvent.oldValue = “xxx”;
notificationEvent.newValue = “yyy”;
...
}
@Test
public void getMessage_eventTypeIsNewCommit_returnXXX() {
NotificationEvent notificationEvent = getNotificationEvent(ResourceType.ISSUE_POST);
notificationEvent.eventType = EventType.NEW_COMMIT;
notificationEvent.oldValue = “xxx”;
notificationEvent.newValue = “yyy”;
...
}
수 많은 테스트 코드들이 존재했고

54.
테스트 코드: 나의 사례 1
@Test
public void getMessage_eventTypeIsIssueBodyChanged_returnXXX() {
NotificationEvent notificationEvent = getNotificationEvent(ResourceType.ISSUE_POST);
notificationEvent.eventType = EventType.ISSUE_BODY_CHANGED;
notificationEvent.oldValue = “xxx”;
notificationEvent.newValue = “yyy”;
...
}
@Test
public void getMessage_eventTypeIsNewCommit_returnXXX() {
NotificationEvent notificationEvent = getNotificationEvent(ResourceType.ISSUE_POST);
notificationEvent.eventType = EventType.NEW_COMMIT;
notificationEvent.oldValue = “xxx”;
notificationEvent.newValue = “yyy”;
...
}
테스트 함수의 이름과 프로덕트 코드를 비교하며 분석할 수 있어요

55.
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)
어랏, 테스트 코드가 있네?
생각보다 적은 시간 들여서 코드 분석 성공!

56.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
테스트 코드: 나의 사례 2

57.
리팩토링이 필요하다의 기준은?
잠깐,
리팩토링이 필요하다의 현실판 기준은 무엇일까요?

58.
리팩토링이 필요하다의 기준은?
● 비즈니스 로직이 아닌 코드를 읽고 있다.
● 하나의 함수에서 두 개 이상의 기능을 읽고 있다.

59.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
테스트 코드: 나의 사례 2

60.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
테스트 코드: 나의 사례 2

61.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
기존 로직 분리만 했으니 테스트 코드 모두 통과하겠지?
테스트 코드: 나의 사례 2

62.
테스트 코드: 나의 사례 2

63.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
기존 로직 분리만 했으니 테스트 코드 모두 통과하겠지?
휴, 테스트 코드 아니었으면 Side Effect 무시하고 배포할 뻔 했네.
테스트 코드: 나의 사례 2

64.
협업 Side Effect
테스트 코드의 장점을 체감한 저의 경험은
‘협업’과 ‘Side Effect’ 2가지 키워드로 요약할 수 있을 것 같아요

65.
협업 Side Effect
새로 입사한 회사의 기존 프로덕트 코드를 분석할 때,
테스트 코드의 도움을 받았구요

66.
협업 Side Effect
기존 프로덕트의 코드를 약간만 수정했을 뿐인데,
어떤 클래스에 영향을 주는지 깨지는 테스트 코드를 통해 발견하게 되었어요

67.
TDD, 테스트 코드 feat. 선배들의 말말말

68.
테스트 코드를 작성하기 어렵다면, 요구사항을 명확하게 정의하지 않았기 때문이다.
출처: ask.fm

69.
TDD is not about the tests – it’s about design
출처: dzone.com

70.
테스트 되지 않은 코드를 리팩토링 하는 것은 러시안 룰렛 같은 짓이다.
출처: facebook.com

71.
감사해요
박미정
mjpark03@gmail.com