SlideShare uma empresa Scribd logo
1 de 71
Baixar para ler offline
엔지니어의 학습,
그리고 테스트 코드
박미정
mjpark03@gmail.com
SI SW
스타트업
프리랜서
(첫 번째 주제)
엔지니어의 학습
(경고)
너무나 당연한 이야기, 지루할 수 있습니다.
엔지니어는 왜 공부해야 하는가?
(이상편: 엔지니어의 본능)
엔지니어는 왜 공부해야 하는가?
● 기술 변화 속도 ● 성능 개선 욕구
엔지니어는 왜 공부해야 하는가?
(현실편: 존경하는 지인 분들에게 물어봤습니다.)
생계형 프로그래머이기 때문에 당장 먹고사는데 필요한 것을 공부해요.
먹고사는데 필요한 만큼 공부해요.
현실편: 1번 지인
만들고 싶은게 많아요. 일단 만들고 싶은게 생기면,
그 과정에서 문제를 만나는 양과 공부의 양이 비례하는 것 같아요.
현실편: 2번 지인
공통점이 보이시나요?
공통점이 보이시나요?
● 동기 부여
엔지니어는 어떻게 공부해야 하는가?
엔지니어는 어떻게 공부해야 하는가?
● 문서 완독 유형
● 필요한 부분 습득 유형
● MOOC 유형
● 남 코드 보기 유형
● 사람 찬스 유형
● 토이 프로젝트 유형
나의 공부 철칙
나의 공부 철칙
● 절대적 시간 확보
● 우선 순위
철칙: 절대적 시간 확보
Welcome to the 얼또
철칙: 절대적 시간 확보
철칙: 우선 순위
요즘 함수형 프로그래밍이 유행이라며?
서버 개발말고 다른 개발도 하고싶어, 앱 개발 공부해볼까?
철칙: 우선 순위
새 회사에서는 Play Framework를 쓰네, 공부하자!
남 코드를 분석할 때 테스트 코드의 도움을 받았으니 제대로 공부해 보자!
2년 가까이 유지한 얼또를 서비스로 만들어보자, 이왕이면 React로?
(두 번째 주제)
그리고 테스트 코드
두 번째 주제인 테스트 코드에 대한 이야기를 해볼까 해요
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
테스트 코드 혹은 테스트 주도 개발에 대한 논쟁은 많죠
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
경험이 미천하여 테스트 코드를 강요하려는 이야기는 아니에요
(주의)
강요가 아니에요, 오히려 반론을 듣고 싶습니다.
다만, 제가 겪은 장점을 기반으로 설득시켜 보고자 해요
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
저는 테스트 코드에 대해 이야기한다고 했죠
테스트 주도 개발에 이야기하려는 건 아니에요
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
가볍게 테스트 주도 개발과 테스트 코드의 정의를 확인하고
구분해 보고자 해요
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
테스트 주도 개발은 소프트웨어 개발 프로세스 방법 중 하나에요
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
절대, 테스트 기법 중 하나가 아니에요
소프트웨어를 개발하는 프로세스 방법 중 하나이죠
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
그럼 테스트 코드의 정의를 살펴볼까요
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
유닛 테스트의 정의를 찾아봤어요
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
유닛 테스트는 소프트웨어 테스트 기법 중 하나이죠
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
테스트 주도 개발의 정의와는 다른 범주의 이야기에요
테스트 코드만 이야기해 볼게요
다시 말씀 드리지만
저는 테스트 코드에 대해 이야기하려 해요
왜 테스트 코드만 이야기 할까요?
테스트 코드 작성이 첫 번째 단계
테스트 주도 개발을 검색하면 자주 볼 수 있는
테스트 주도 개발 사이클을 도식화한 그림이죠
테스트 코드 작성이 첫 번째 단계
보시는 것 처럼 실패하는 테스트 코드를 작성하는 일이 첫 번째 단계에요
테스트 코드 작성이 첫 번째 단계
만약 첫 번째 단계인 테스트 코드를 작성하는 일이
납득되지 않거나 익숙하지 않다면
테스트 코드 작성이 첫 번째 단계
테스트 주도 개발을 이해하는 것도 불가능에 가깝겠죠
테스트 코드 작성이 첫 번째 단계
사실 이건 두 번째 이유이고
테스트 코드 작성이 첫 번째 단계
진짜 이유는
아직 테스트 주도 개발을 짧은 시간에 전달하기에는
테스트 코드 작성이 첫 번째 단계
제 경험이 부족하네요 (땀)
테스트 코드를 반대하는 사람들의 의견은?
테스트 코드: 반대
프로덕트 코드보다 테스트 코드가 너무 길어져요
테스트 코드: 반대
테스트 코드가 생각보다 많은 것을 해결하지 않아요
테스트 코드: 반대
테스트 코드를 만들기 위한 너무 지식이 많이 필요해요
테스트 코드를 찬성하는 사람들의 의견은?
테스트 코드: 찬성
프로덕트 코드를 더 잘 이해하게 되요
프로덕트 코드보다 테스트 코드가 너무 길어져요
테스트 코드: 찬성
테스트 코드는 적어도 최소한의 문제를 해결해요
테스트 코드가 생각보다 많은 것을 해결하지 않아요
테스트 코드: 찬성
제대로 하기 위해 노력이 필요하지 않은 분야가 있나요?
테스트 코드를 만들기 위한 지식이 너무 많이 필요해요
테스트 코드에 찬성하는 나의 실제 사례?
그럼 테스트 코드에 찬성하는
저의 실제 사례를 이야기해볼까 해요
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)
어랏, 테스트 코드가 있네?
테스트 코드: 나의 사례 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”;
...
}
수 많은 테스트 코드들이 존재했고
테스트 코드: 나의 사례 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”;
...
}
테스트 함수의 이름과 프로덕트 코드를 비교하며 분석할 수 있어요
테스트 코드: 나의 사례 1
이벤트 유형에 따라 알림 메시지를 반환하는 기능 분석 필요하다.
이벤트 유형이 너무 많아서 기존 로직이 길다. (생각보다 시간이 오래 걸리겠군)
어랏, 테스트 코드가 있네?
생각보다 적은 시간 들여서 코드 분석 성공!
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
테스트 코드: 나의 사례 2
리팩토링이 필요하다의 기준은?
잠깐,
리팩토링이 필요하다의 현실판 기준은 무엇일까요?
리팩토링이 필요하다의 기준은?
● 비즈니스 로직이 아닌 코드를 읽고 있다.
● 하나의 함수에서 두 개 이상의 기능을 읽고 있다.
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
테스트 코드: 나의 사례 2
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
테스트 코드: 나의 사례 2
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
기존 로직 분리만 했으니 테스트 코드 모두 통과하겠지?
테스트 코드: 나의 사례 2
테스트 코드: 나의 사례 2
새 기능을 개발하려고 보니, 리팩토링이 필요한 기존 코드 발견.
단위 기능으로 분리할 수 있는 함수들을 도출하자.
도출한 김에 지난 번에 이야기했던 diff style 변경도 같이 하자.
기존 로직 분리만 했으니 테스트 코드 모두 통과하겠지?
휴, 테스트 코드 아니었으면 Side Effect 무시하고 배포할 뻔 했네.
테스트 코드: 나의 사례 2
협업 Side Effect
테스트 코드의 장점을 체감한 저의 경험은
‘협업’과 ‘Side Effect’ 2가지 키워드로 요약할 수 있을 것 같아요
협업 Side Effect
새로 입사한 회사의 기존 프로덕트 코드를 분석할 때,
테스트 코드의 도움을 받았구요
협업 Side Effect
기존 프로덕트의 코드를 약간만 수정했을 뿐인데,
어떤 클래스에 영향을 주는지 깨지는 테스트 코드를 통해 발견하게 되었어요
TDD, 테스트 코드 feat. 선배들의 말말말
테스트 코드를 작성하기 어렵다면, 요구사항을 명확하게 정의하지 않았기 때문이다.
출처: ask.fm
TDD is not about the tests – it’s about design
출처: dzone.com
테스트 되지 않은 코드를 리팩토링 하는 것은 러시안 룰렛 같은 짓이다.
출처: facebook.com
감사해요
박미정
mjpark03@gmail.com

Mais conteúdo relacionado

Mais procurados

Test driven development
Test driven developmentTest driven development
Test driven developmentJinho Song
 
코드 리뷰 시스템 소개
코드 리뷰 시스템 소개코드 리뷰 시스템 소개
코드 리뷰 시스템 소개Young-Ho Cha
 
Code Review - DevOn2013
Code Review - DevOn2013Code Review - DevOn2013
Code Review - DevOn2013호정 이
 
TDD: Test Driven Development 첫번째 이야기
TDD: Test Driven Development 첫번째 이야기TDD: Test Driven Development 첫번째 이야기
TDD: Test Driven Development 첫번째 이야기Ji Heon Kim
 
TDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDTDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDSuwon Chae
 
5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스NAVER D2
 
C++ 코드 품질 관리 비법
C++ 코드 품질 관리 비법C++ 코드 품질 관리 비법
C++ 코드 품질 관리 비법선협 이
 
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기NAVER Engineering
 
플리토 코드리뷰 - Code Review in Flitto
플리토 코드리뷰 - Code Review in Flitto플리토 코드리뷰 - Code Review in Flitto
플리토 코드리뷰 - Code Review in FlittoYongjun Kim
 
애자일 안한 이야기
애자일 안한 이야기애자일 안한 이야기
애자일 안한 이야기Sungchul Park
 
테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)KH Park (박경훈)
 
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)NAVER Engineering
 
도도와 파이썬: 좋은 선택과 나쁜 선택
도도와 파이썬: 좋은 선택과 나쁜 선택도도와 파이썬: 좋은 선택과 나쁜 선택
도도와 파이썬: 좋은 선택과 나쁜 선택Jc Kim
 
Java 그쪽 동네는
Java 그쪽 동네는Java 그쪽 동네는
Java 그쪽 동네는도형 임
 
E1_Deview nhn애자일개발 tdd_질문답
E1_Deview nhn애자일개발 tdd_질문답E1_Deview nhn애자일개발 tdd_질문답
E1_Deview nhn애자일개발 tdd_질문답NAVER D2
 
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님NAVER D2
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님NAVER D2
 
코드의 품질 (Code Quality)
코드의 품질 (Code Quality)코드의 품질 (Code Quality)
코드의 품질 (Code Quality)ChulHui Lee
 
학교에선 알려주지 않는 오픈소스이야기 - 박치완님
학교에선 알려주지 않는 오픈소스이야기 - 박치완님학교에선 알려주지 않는 오픈소스이야기 - 박치완님
학교에선 알려주지 않는 오픈소스이야기 - 박치완님NAVER D2
 

Mais procurados (19)

Test driven development
Test driven developmentTest driven development
Test driven development
 
코드 리뷰 시스템 소개
코드 리뷰 시스템 소개코드 리뷰 시스템 소개
코드 리뷰 시스템 소개
 
Code Review - DevOn2013
Code Review - DevOn2013Code Review - DevOn2013
Code Review - DevOn2013
 
TDD: Test Driven Development 첫번째 이야기
TDD: Test Driven Development 첫번째 이야기TDD: Test Driven Development 첫번째 이야기
TDD: Test Driven Development 첫번째 이야기
 
TDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDTDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDD
 
5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스5.yobi를 활용한 개발자 협업 및 배포 프로세스
5.yobi를 활용한 개발자 협업 및 배포 프로세스
 
C++ 코드 품질 관리 비법
C++ 코드 품질 관리 비법C++ 코드 품질 관리 비법
C++ 코드 품질 관리 비법
 
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기
200819 NAVER TECH CONCERT 07_신입 iOS 개발자 개발업무 적응기
 
플리토 코드리뷰 - Code Review in Flitto
플리토 코드리뷰 - Code Review in Flitto플리토 코드리뷰 - Code Review in Flitto
플리토 코드리뷰 - Code Review in Flitto
 
애자일 안한 이야기
애자일 안한 이야기애자일 안한 이야기
애자일 안한 이야기
 
테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)
 
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
 
도도와 파이썬: 좋은 선택과 나쁜 선택
도도와 파이썬: 좋은 선택과 나쁜 선택도도와 파이썬: 좋은 선택과 나쁜 선택
도도와 파이썬: 좋은 선택과 나쁜 선택
 
Java 그쪽 동네는
Java 그쪽 동네는Java 그쪽 동네는
Java 그쪽 동네는
 
E1_Deview nhn애자일개발 tdd_질문답
E1_Deview nhn애자일개발 tdd_질문답E1_Deview nhn애자일개발 tdd_질문답
E1_Deview nhn애자일개발 tdd_질문답
 
개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님개발을잘하고싶어요-네이버랩스 송기선님
개발을잘하고싶어요-네이버랩스 송기선님
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님
 
코드의 품질 (Code Quality)
코드의 품질 (Code Quality)코드의 품질 (Code Quality)
코드의 품질 (Code Quality)
 
학교에선 알려주지 않는 오픈소스이야기 - 박치완님
학교에선 알려주지 않는 오픈소스이야기 - 박치완님학교에선 알려주지 않는 오픈소스이야기 - 박치완님
학교에선 알려주지 않는 오픈소스이야기 - 박치완님
 

Semelhante a 엔지니어의 학습, 그리고 테스트 코드

초보개발자의 TDD 체험기
초보개발자의 TDD 체험기초보개발자의 TDD 체험기
초보개발자의 TDD 체험기Sehun Kim
 
testing for agile?, agile for testing
testing for agile?, agile for testingtesting for agile?, agile for testing
testing for agile?, agile for testingSangIn Choung
 
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기Ahreum Kim
 
행복한 개발을 위한_테스트_케이스
행복한 개발을 위한_테스트_케이스행복한 개발을 위한_테스트_케이스
행복한 개발을 위한_테스트_케이스도형 임
 
[H3 2012] 행복한 개발을 위한 테스트 케이스
[H3 2012] 행복한 개발을 위한 테스트 케이스[H3 2012] 행복한 개발을 위한 테스트 케이스
[H3 2012] 행복한 개발을 위한 테스트 케이스KTH, 케이티하이텔
 
테스트자동화와 TDD
테스트자동화와 TDD테스트자동화와 TDD
테스트자동화와 TDDSunghyouk Bae
 
오픈 소스와 코드 리뷰
오픈 소스와 코드 리뷰오픈 소스와 코드 리뷰
오픈 소스와 코드 리뷰Daniel Juyung Seo
 
발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법SangIn Choung
 
프로젝트 관리 및 지켜야 할 사항들
프로젝트 관리 및 지켜야 할 사항들프로젝트 관리 및 지켜야 할 사항들
프로젝트 관리 및 지켜야 할 사항들Lee Geonhee
 
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)SangIn Choung
 
전통적인 개발과 테스트 주도 개발, 그리고 애자일
전통적인 개발과 테스트 주도 개발, 그리고 애자일전통적인 개발과 테스트 주도 개발, 그리고 애자일
전통적인 개발과 테스트 주도 개발, 그리고 애자일Tap ToRestart
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다이상한모임
 
Testing & refactoring
Testing & refactoringTesting & refactoring
Testing & refactoringLim Hosung
 
테스트 냄새
테스트 냄새테스트 냄새
테스트 냄새SukYun Yoon
 
클린코드와 테스트코드
클린코드와 테스트코드클린코드와 테스트코드
클린코드와 테스트코드Herren
 
TDD.JUnit.조금더.알기
TDD.JUnit.조금더.알기TDD.JUnit.조금더.알기
TDD.JUnit.조금더.알기Wonchang Song
 
Devon 2011-b-5 효과적인 레거시 코드 다루기
Devon 2011-b-5 효과적인 레거시 코드 다루기Devon 2011-b-5 효과적인 레거시 코드 다루기
Devon 2011-b-5 효과적인 레거시 코드 다루기Daum DNA
 
DebugIt/chapter1~4
DebugIt/chapter1~4DebugIt/chapter1~4
DebugIt/chapter1~4stupidfox
 
테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션SangIn Choung
 

Semelhante a 엔지니어의 학습, 그리고 테스트 코드 (20)

초보개발자의 TDD 체험기
초보개발자의 TDD 체험기초보개발자의 TDD 체험기
초보개발자의 TDD 체험기
 
testing for agile?, agile for testing
testing for agile?, agile for testingtesting for agile?, agile for testing
testing for agile?, agile for testing
 
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기
 
행복한 개발을 위한_테스트_케이스
행복한 개발을 위한_테스트_케이스행복한 개발을 위한_테스트_케이스
행복한 개발을 위한_테스트_케이스
 
[H3 2012] 행복한 개발을 위한 테스트 케이스
[H3 2012] 행복한 개발을 위한 테스트 케이스[H3 2012] 행복한 개발을 위한 테스트 케이스
[H3 2012] 행복한 개발을 위한 테스트 케이스
 
테스트자동화와 TDD
테스트자동화와 TDD테스트자동화와 TDD
테스트자동화와 TDD
 
오픈 소스와 코드 리뷰
오픈 소스와 코드 리뷰오픈 소스와 코드 리뷰
오픈 소스와 코드 리뷰
 
발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법
 
프로젝트 관리 및 지켜야 할 사항들
프로젝트 관리 및 지켜야 할 사항들프로젝트 관리 및 지켜야 할 사항들
프로젝트 관리 및 지켜야 할 사항들
 
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
 
전통적인 개발과 테스트 주도 개발, 그리고 애자일
전통적인 개발과 테스트 주도 개발, 그리고 애자일전통적인 개발과 테스트 주도 개발, 그리고 애자일
전통적인 개발과 테스트 주도 개발, 그리고 애자일
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다
 
Testing & refactoring
Testing & refactoringTesting & refactoring
Testing & refactoring
 
테스트 냄새
테스트 냄새테스트 냄새
테스트 냄새
 
클린코드와 테스트코드
클린코드와 테스트코드클린코드와 테스트코드
클린코드와 테스트코드
 
Tdd
TddTdd
Tdd
 
TDD.JUnit.조금더.알기
TDD.JUnit.조금더.알기TDD.JUnit.조금더.알기
TDD.JUnit.조금더.알기
 
Devon 2011-b-5 효과적인 레거시 코드 다루기
Devon 2011-b-5 효과적인 레거시 코드 다루기Devon 2011-b-5 효과적인 레거시 코드 다루기
Devon 2011-b-5 효과적인 레거시 코드 다루기
 
DebugIt/chapter1~4
DebugIt/chapter1~4DebugIt/chapter1~4
DebugIt/chapter1~4
 
테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션
 

엔지니어의 학습, 그리고 테스트 코드

  • 1. 엔지니어의 학습, 그리고 테스트 코드 박미정 mjpark03@gmail.com
  • 4. (경고) 너무나 당연한 이야기, 지루할 수 있습니다.
  • 5. 엔지니어는 왜 공부해야 하는가? (이상편: 엔지니어의 본능)
  • 6. 엔지니어는 왜 공부해야 하는가? ● 기술 변화 속도 ● 성능 개선 욕구
  • 7. 엔지니어는 왜 공부해야 하는가? (현실편: 존경하는 지인 분들에게 물어봤습니다.)
  • 8. 생계형 프로그래머이기 때문에 당장 먹고사는데 필요한 것을 공부해요. 먹고사는데 필요한 만큼 공부해요. 현실편: 1번 지인
  • 9. 만들고 싶은게 많아요. 일단 만들고 싶은게 생기면, 그 과정에서 문제를 만나는 양과 공부의 양이 비례하는 것 같아요. 현실편: 2번 지인
  • 13. 엔지니어는 어떻게 공부해야 하는가? ● 문서 완독 유형 ● 필요한 부분 습득 유형 ● MOOC 유형 ● 남 코드 보기 유형 ● 사람 찬스 유형 ● 토이 프로젝트 유형
  • 15. 나의 공부 철칙 ● 절대적 시간 확보 ● 우선 순위
  • 16. 철칙: 절대적 시간 확보 Welcome to the 얼또
  • 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
  • 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