1.
Test-Driven Development
basic
Jinwoo Park, XFT-Aries, LMR PD TC3 Team

2.
2
1. Test-Driven Development?
2. By Example: Action speaks louder than words
3. By Demonstration: 실천궁행(實踐躬行)
4. TDD Basic Strategy
5. Testing Pattern
6. Refactoring
7. Design Patterns in Test Framework: JUnit
8. Retrospective..
9. My & Your Assignment
10.Reference
Contents

3.
3
› Learning how to do TDD
› NO!
› Learning the philosophy
› YES!
› So, How?
› 배운것을 실천하며 체득한다! : 지행일치(知行一致)
GOAL

4.
4
Test-driven development?
Test-driven development
› 한국어로는 테스트 주도 개발
잠시만 안녕..
› 테스트? 주도 개발? 흠..
› 단일사고적(Monological) 접근으로!
› 논제를 쪼개보자.
›테스트 / 주도 개발

5.
5
Test-driven development?
Test
› 도와줘요! 네이버사전!
› v. Test: 수작업의 느낌
› n. Test: 자동화된 느낌
› Quiz. TDD의 Test는 명사인가? 동사인가?

6.
6
Test-driven development?
Automated Test
› 모든 테스트 케이스를 코드 스크립트로 변환한 집합체
<MCT Test>

7.
7
Test-driven development?
Why we need it?
› 소프트웨어의 소스는 복잡하게 연결되어 있다.

8.
8
Test-driven development?
Why we need it?
› 여기서 작은 부분이 수정된다면??
마음이 불안해진다..

9.
9
Test-driven development?
Why we need it?
› 모든 기능을 다시 테스트해야 한다.

10.
10
Test-driven development?
Why we need it?
› 또한 소스코드는 시간이 지나며 녹이 슨다.

11.
11
Test-driven development?
Why we need it?
› 끊임없는 리펙토링이 필요.

12.
12
Test-driven development?
Why we need it?
› 하지만 리펙토링이 녹록치 않다.
“We are waiting for you!”

13.
13
Test-driven development?
Why we need it?
› 이 경우도 모든 기능을 다시 테스트 해야 한다.

14.
14
Test-driven development?
No automated test?
› 버그 검출 능력 저하
› 소스 코드 품질 저하
› 자체 테스트 비용의 증가

15.
15
Test-driven development?
So, Test automation == TDD ??
› 그렇다면 테스트 자동화가 곧 TDD일까?
Test -Driven Development
이제 헤어지지 말자..
› 생각을 확장할 때가 되었다.

16.
16
Test-driven development?
Architecture-driven development
› 남녀노소 익숙한 개발 주기
설계
코딩
테스트
Next Cycle
› 자동화된 테스트코드의 작성이 불가능할까?

17.
17
Test-driven development?
However..
› 누구나 겪어봤을 고통..
1. 설계: 불행하게도 초반에 완벽한 설계를 하기는 힘들다.
2. 코딩: 설계가 완벽하지 않기에 코딩이 산으로 간다.
3. 테스트: 설계<->코딩 주기를 반복하며, 요구사항이 어느
정도 구현되고 나서야 작성되기 시작한다.
4. 요구사항변경 or 설계미스발견: 테스트 코드작성은
아직 미완상태. 이제 모든것이 꼬이기 시작한다..
5. 리펙토링: 포기.

18.
18
Test-driven development?
Again.. Again.. And again..
› 이런 상황이 계속되어 버리면..
스트레스
테스트
외부변수
악영향
악영향
<Influence Diagram>

19.
19
Test-driven development?
It makes uncertainty
› 불확실성은 두려움을 만든다. 두려움은 우리를..
1. 망설이게 만든다.
2. 커뮤니케이션을 덜 하게 한다.
3. 피드백 받는 것을 피하도록 한다.

20.
20
Test-driven development?
So we need courage!
› 용기를 얻기 위해선 어떻게 해야할까.
1. 불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 시작
한다.
2. 침묵을 지키는 대신 좀 더 분명하게 커뮤니케이션을 한다.
3. 피드백을 회피하지 말고 도움이 되는 구체적인 피드백을 찾는다.

21.
21
Test-driven development?
For what?
› “Clean Code that works” – Ron Jeffries
› 궁극적 목표는 바로 “작동하는 깔끔한 코드”를 작성하는
것!

22.
22
Test-driven development?
So.. How?
› 발상의 전환!
테스트우선
스트레스
외부변수
긍정적효과
긍정적효과
<Influence Diagram>

23.
23
Test-driven development?
Test drives development
› 즉, 개발 주기에서 테스트 작성을 우선시한다!
TestCoding
“난 더이상 네 개가 아냐.”

24.
24
Test-driven development?
This is Test-driven development!
테스트
실패를 확인
테스트를
통과시킨다
테스트
성공을 확인
작은 크기의
테스트작성
리펙토링
Next Cycle

25.
25
Test-driven development?
What is the advantage?
› 아는 것을 행할시간.
› 실천을 통해 체감해본다.

26.
26
By Example
Scenario
› 회사가 판매하는 채권 포트폴리오 관리 시스템의 새로운 고
객이 문득 이런 요구사항을 던진다.
"시스템이 제공하는 기능들에 굉장히 감탄했습니다. 헌데, 미
합중국 달러로 명명된 채권만 다루고 있더군요.
저는 새로운 채권 펀드를 시작하려고 하는데 제 전략상 다른
화폐로 채권을 다룰 필요가 있습니다.“

27.
27
By Example
System implementation
› 시스템이 기존에 제공했던 기능은 다음과 같을 것이다.
종목 주 가격 합계
IBM 1000 25 25000
GE 400 100 40000
합계 65000

28.
28
By Example
System implementation
› To-Do List를 작성해본다.
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD

29.
29
By Example
System implementation
› 테스트 코드를 작성해본다.
› 컴파일 실패!
1. 아직 Dollar 클래스가 존재하지 않는다.
2. Dollar 내부엔 int를 입력받는 생성자가 필요할 것이다.
3. Dollar 내부엔 times(int) 라는 함수가 필요할 것이다.

30.
30
By Example
System implementation
› 재빠르고 비열하게 코드를 작성한다.
› 컴파일 성공!

31.
31
By Example
System implementation
› 테스트를 실행해본다.
› 테스트 실패!

32.
32
By Example
System implementation
› 비열하게 테스트를 통과시켜보자.
› 컴파일 성공!

33.
33
By Example
System implementation
› 비열하게 테스트를 통과시켜보자.
› 테스트 성공!

34.
34
By Example
System implementation
› 마지막 단계! 리펙토링.
› 상수로 선언된 부분을 추상화한다.

35.
35
By Example
System implementation
› 코드를 변경하였으니 테스트를 통과시켜보자.
› 테스트 성공!

36.
36
By Example
System implementation
› To-Do List를 갱신한다.
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD

37.
37
By Example
System implementation
› 시스템이 앞으로 제공해야 할 기능은 다음과 같을 것이다.
종목 주 가격 합계
IBM 1000 25USD 25000USD
Novartis 400 150CHF 60000CHF
합계 65000USD
※ 환율 : 1.5CHF = 1USD

38.
38
By Example
System implementation
› To-Do List를 갱신한다.
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
- USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc

39.
39
By Example
System implementation
› 테스트 코드를 작성해본다.
› 컴파일 실패!
1. 아직 Franc 클래스가 존재하지 않는다.
2. Franc 내부엔 int를 입력받는 생성자가 필요할 것이다.
3. Franc 내부엔 times(int) 라는 함수가 필요할 것이다.

40.
40
By Example
System implementation
› Dollar Class를 이용하여 Franc 클래스를 만든다.
› 물론, 테스트는 성공한다.

41.
41
By Example
System implementation
› 리펙토링 단계
› Dollar클래스와 Franc 클래스 사이의 중복들이 거슬린다.
› 둘을 묶을 수 있는 상위 클래스가 있다면 어떨까?
› To-Do List는 항상 열려있다.
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
- USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc
- Dollar와 Franc 클래스의 상위 클래스인 Money 클래스

42.
42
By Example
System implementation
› Money 클래스 작성.

43.
43
By Example
System implementation
› Dollar 클래스 변경.

44.
44
By Example
System implementation
› Franc 클래스 변경.

45.
45
By Example
System implementation
› 테스트 성공
› 이번 사이클에서는 Dollar와 Franc에 대폭 변화가 있었다.
› 기존 테스트들이 Dollar와 Franc의 기능을 검증해준다!
›코드 변경에 용기가 샘솟는다!

46.
46
By Example
System implementation
› 리펙토링.
› 중복을 제거하자
1. 생성자 중복
2. 멤버변수 중복
3. times(int) 중복

47.
47
By Example
System implementation
› Money: 변경이 없다.

48.
48
By Example
System implementation
› Dollar, Franc: 부모클래스가 제공하는 Method를 이용한다.
› 테스트 통과 확인!

49.
49
By Example
System implementation
› To-Do List 갱신
› Dollar와 Franc의 amount가 같더라도 둘의 가치는 다르다.
› Dollar와 Franc 클래스를 비교하는 기능이 필요하다.
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
- USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc
- Dollar와 Franc 클래스의 상위 클래스인 Money 클래스
- Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)

50.
50
By Example
System implementation
› 테스트 코드 작성
› 컴파일 에러
› equal(Money*)함수가 존재하지 않는다.

51.
51
By Example
System implementation
› Money: equal(Money*)함수 구현

52.
52
By Example
System implementation
› 테스트 실패
› 환율에 대한 고려가 전혀 없다.

53.
53
By Example
System implementation
› 테스트를 통과하려면? (전략수립)
1. Dollar와 Franc에서 각각의 통화가 무엇인지 기억한다.
2. 객체간 비교시, 각 개체의 통화정보를 기준으로 USD로 변
경한 후 비교를 수행한다.
3. 환율정보를 갖고 있는 ‘무언가’가 필요하다.
4. ‘무언가’의 이름으로는 Bank가 적절할 것 같다.

54.
54
By Example
System implementation
› 다시 테스트 코드 작성
› 컴파일 에러
› Bank 클래스가 존재하지 않는다
› equal(Bank, Money*)함수의 입력형태가 이전과 다르다

55.
55
By Example
System implementation
› Bank Class 작성1
› 각 화폐는 addRate시, 자신이 갖고있는 currency 식별자를
입력할 것이다.

56.
56
By Example
System implementation
› Bank Class 작성2

57.
57
By Example
System implementation
› Money Class: 화폐 식별자 currency 추가

58.
58
By Example
System implementation
› Money Class: equal(Bank, Money*) 변경
› Bank에서 얻은 환율정보로 모든 화폐를 USD로 변경한다.

59.
59
By Example
System implementation
› Dollar Class, Franc Class 작성
› 각 화폐 생성시 자신의 식별자가 setting된다.

60.
60
By Example
System implementation
› 또 다시 테스트 실패
› 테스트 케이스에서 환율에 대한 정보를 입력하지 않았다.
› bank.addRate(“USD”, 1.0); //추가
› bank.addRate(“CHF”, 1.0); //추가

61.
61
By Example
System implementation
› 테스트가 통과하는 것을 확인

62.
62
By Example
System implementation
› To-Do List 갱신
› 드디어 서로 다른 통화간의 합이 남았다
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
- USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc
- Dollar와 Franc 클래스의 상위 클래스인 Money 클래스
- Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)

63.
63
By Example
System implementation
› 테스트 코드 작성
› 컴파일에러!
› Money에 add(Bank, Money*, string)가 추가되어야 한다.

64.
64
By Example
System implementation
› Money Class: add 함수 작성
› Money에 통화단위를 입력받는 생성자가 필요하다.

65.
65
By Example
System implementation
› Money Class: 생성자 작성
› 이로써 모든 테스트가 통과했다.
› 예외처리, 리펙토링 등은 분량상 생략.

66.
66
By Example
System implementation
› To-Do List 갱신
To-Do List
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5USD = 10USD
- USD와 CHF를 더해서 USD로 나타내는 기능 : 10USD + 15CHF = 20USD
- 가격과 주를 곱해서 총 합계를 구하는 기능 : 2 * 5Franc = 10Franc
- Dollar와 Franc 클래스의 상위 클래스인 Money 클래스
- Dollar와 Franc 클래스의 비교 : Dollar(5) != Franc(5)

67.
67
By Example
Does it make a sense?
› 머리가 복잡하시죠?

68.
68
By Example
Does it make a sense?
› 방금 본 것은 잠시 잊으셔도 좋습니다.
›더 쉬운 예제로!
›눈 앞에서 직접!

69.
69
By Demonstration
Fibonacci series

70.
70
TDD basic strategy
Independent test
› 각 테스트는 독립성이 보장되어야 한다.
› 테스트는 충분히 빨라야한다.
Q. 테스트의 독립성을 위해 Test마다 시스템을 재가동 한다면
?
Q. 재빠른 테스트를 위해 한 가지 Test 내에서 두 가지 이상의
기능을 검증한다면?
› 잘만 지키면, 설계 응집도는 상승하고 결합도는 낮아진다.

71.
71
TDD basic strategy
To-do list
› 적는 습관을 들인다!
› TO-DO LIST는 카테고리 별로 잘 정리한다!
-> 규모, 우선순위 등등
› 머릿속에만 의지하게 되면..
1. 경험이 축적될수록 TO-DO LIST가 많아진다.
2. LIST가 많을 수록 집중도가 떨어진다.
3. 집중도가 떨어지면 실수가 발생한다.

72.
72
TDD basic strategy
Bottom-Up? Top-down?
› 간단한 한가지 사례를 나타내는 테스트에서 시작했다면?
-> Top-Down 식 구현.
› 전체의 작은 한 조각에 해당하는 테스트에서 시작했다면?
-> Bottom-UP 식 구현.
› 즉, TDD는 상향 또는 하향에 종속된 개념이 아니다.
‘Known-to-unknown’

73.
73
TDD basic strategy
Assert first
› Test를 작성시 Assert를 제일 먼저 쓰고 시작하라.
› 시스템의 주요한 요구사항을 극도로 추상화 시킬 수 있다.

74.
74
Testing pattern
Mock object
› 서버에 대한 테스트가 필요한데, 클라이언트가 없을 경우,
› 원격서버와의 통신중 물리환경에 의해 테스트가 실패될 때,
› 테스트 중 상대 객체에 대한 호출내역이 궁금할 때,
모의객체 (Mock Object)로 원하는 상황을 연출가능!

75.
75
Testing pattern
Crash test dummy
› 에러 상황에 대해 테스트할 때 사용
› 객체 전체를 흉내내지 않는 점을 제외하면 Mock Object와 유
사.
› EX)
파일 시스템에 여유공간이 없는 상황을 연출하고 싶을 때.

76.
76
Testing pattern
Crash test dummy
Private class FullFile extends File {
public FullFile(String path) {
super(path);
}
public boolean createNewFile() throws IOException {
throw new IOException();
}
}

77.
77
Testing pattern
Crash test dummy
public void testFileSystemError(){
File f = new FullFile(“foo”);
try{
saveAs(f);
fail(); // 예외처리에 실패하면 테스트가 종료
} catch(IOException e) {
// Do Something
}
}

78.
78
Refactoring
Main idea
› 중복을 제거한다.
› 구체화 -> 추상화시킨다.
› 과도한 제어흐름은 단순화 시킨다.

79.
79
Design patterns
in junit
xunit?
› xUnit 은 스몰토크4의 테스트 프레임워크 SUnit 의 구조와 함
수들을 따라한 유닛 테스팅 프레임워크들을 총칭.
› 첫 글자는 사용하는 언어에서 따온다.
› 즉, JUnit은 자바를 위한 테스트 프레임워크다.

80.
80
Design patterns
in junit
Junit patterns summary

81.
81
Retrospective
Through TDD?
› 짧은 사이클의 반복으로 설계 방향을 누차 재점검 할 수 있다.
변화가 빨리 도입되는 극한적 상황에서 유리하다.
› 커뮤니케이션의 용이해진다. 테스트 코드는 곧 작업에 대한
history이기도 하다.
› 한참 뒤에 들이닥치는 변동사항에도 끄떡없다.

82.
82
Retrospective
Once again, TDD?
› TDD는 테스팅 기술이 아니다.
분석 기술이며, 설계기술이기도 하다.
› 또한 개발의 모든 활동을 구조화하는 기술이다.
FOR
Clean code that works

83.
83
My & your assignment
What else?
› 실제로 해보기! 많이!
› 읽어보기: TDD is dead long live testing by DHH
› 시청하기: 유닛테스트의 효용성 by 김포프
› TDD에 대한 ‘나’의 입장 정리해보기.

84.
84
[1] Test Driven Development: By Examples, Kent Beck
[2] 테스트 주도 개발 (Test-Driven Development), 박상준
[3] 테스트 자동화와 TDD, 박경훈
[4] JUnit A Cook's Tour
[5] Java Reflection API, stackoverflow
[6] Design Patterns, Programcreek
[7] Extreme Programming, Wikipedia
[8] TDD는 죽었다, DHH, 이상욱 역
[9] C++ 유닛테스트, 김포프
references