Skip to content

Commit 0ab9449

Browse files
committed
add : 패캠 The RED 현실 세상의 TDD
- 테스트 코드 - 테스트 우선 개발 - 작업 환경 정리 - 테스트 주도 개발 - 켄트 백의 설계 규칙 - 기대 출력 피드백 - 오버엔지니어링 - 핵심은 피드백
1 parent bba8bc0 commit 0ab9449

File tree

1 file changed

+92
-0
lines changed

1 file changed

+92
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
# 개요
2+
3+
TEST 코드는 어떤 생각을 가지고 어떻게 작성하는 것이 올바른지 학습하기 위해서
4+
패캠 The RED : 이규원의 현실 세상의 TDD : 안정감을 주는 코드 작성 방법 강의를 수강하며,
5+
TDD에 대한 내용을 정리한다
6+
7+
- [개요](#개요)
8+
- [테스트 코드](#테스트-코드)
9+
- [테스트 우선 개발](#테스트-우선-개발)
10+
- [작업 환경 정리](#작업-환경-정리)
11+
- [테스트 주도 개발](#테스트-주도-개발)
12+
- [켄트 벡의 설계 규칙](#켄트-벡의-설계-규칙)
13+
- [기대 출력 피드백](#기대-출력-피드백)
14+
- [오버엔지니어링](#오버엔지니어링)
15+
- [핵심은 피드백](#핵심은-피드백)
16+
17+
## 테스트 코드
18+
19+
- 요구사항으로 도출된 가시적이고 구체적인 목표
20+
- 자가검증 능력을 가짐
21+
- 반복실행이 가능하며
22+
- 운영 코드의 실제 클라이언트 중 하나가 됨
23+
24+
## 테스트 우선 개발
25+
26+
- 테스트를 먼저 작성하고 개발을 한다
27+
- 명확하고 검증 가능한 목표를 설정한 후 목표를 달성
28+
- 프로세스가 코딩에 앞선 목표 설정을 강요
29+
- 프로그래머는 자신이 풀어야할 문제를 구체적으로 이해해야 함
30+
31+
-> 구조적으로 프로그래머가 해당 기능을 구체적으로 파악하게하는 효과
32+
33+
## 작업 환경 정리
34+
35+
- `생산성` : 정리된 환경과 어지렵혀진 환경에서의 작업 생산성 차이
36+
- `지속성` : 작업 환경의 생산성이 일정 수준 미만으로 떨어지면 더 이상 그 환경에서 작업 진행 불가능
37+
38+
우리는 이를 `리팩터링`이라 부른다. 리팩터링에 대해서 알아보자
39+
40+
- `팩터링` : 의미를 유지하며 숫자나 대상을 더 작은 단위로 나눈다.
41+
- `리팩터링` : 의미를 유지하며 코드베이스를 다시 정리
42+
43+
## 테스트 주도 개발
44+
45+
테스트 주도 개발 절차는 아래 과정을 반복한다.
46+
47+
`RED`(실패하는 테스트 추가) -> `GREEN`(테스트 통과, 최소한의 코딩) -> `REFACTOR`(구현 설계 개선, 테스트 통과 유지)
48+
49+
- `테스트 실패`
50+
- 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가
51+
- 추가된 테스트가 실패하는지 확인
52+
- 실패하는 것을 확인해야 테스트가 동작함을 믿을 수 있다.
53+
- 운영 코드 변경이 진행되지 않았기 때문에 실패했는지 확인해야 한다.
54+
- `테스트 성공`
55+
- 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영 코드를 변경
56+
- 테스트 성공은 요구사항 만족을 의미
57+
- ***테스트 성공을 위한 최소한의 변경** -> 추가적인 코드를 작성한다는 건 테스트되지 않은 코드를 추가하는 행위
58+
- 테스트를 통과하는 코드를 빠르게 작성하는 것이 효율적
59+
- `리팩터링`
60+
- 코드베이스 정리
61+
- 구현 설계 개선(가독성, 적응성, 성능)
62+
- ***모든 테스트 성공을 전제**
63+
64+
## 켄트 벡의 설계 규칙
65+
66+
- Passes the tests : 테스트 통과
67+
- Reveals intention : 의도 노출(가독성)
68+
- No duplication : 중복 제거
69+
- Fewest elements : 가장 적은 요소(앞선 과정에 필요없는 코드는 제거)
70+
71+
https://martinfowler.com/bliki/BeckDesignRules.html
72+
73+
## 기대 출력 피드백
74+
75+
프로그래머는 피드백을 통해 프로그램을 발전시킨다.
76+
77+
- `사용자 피드백` : 사용자가 직접 코드를 사용한 후 경험한 버그나 불만을 제보
78+
- `QA(Quality Assurance)` : 전문 인적 자원에 의한 인수 테스트
79+
- `프로그래머 테스트` : 프로그래머가 직접 피드백 장치를 준비(테스트 코드 등)
80+
- `도구 피드백` : 컴파일 오류, 정적 검사 등 프로그래머가 사용하는 도구가 제공하는 피드백
81+
82+
## 오버엔지니어링
83+
84+
- 프로그래머는 요구사항 명세에 **명확히 지정되지 않은 성능 달성이나 구현 설계 품질 개선에 빠져드는 경향**을 가짐
85+
- 이런 목표는 그 자체로 나쁜 것이 아니지만 지나치면 더 중요한 목적, 기능 요구사항에 써야할 자원을 불필요하게 낭비하게 됨
86+
87+
- `테스트 주도 개발`은 가장 중요한 목표를 우선 달성하도록 유도하며, 오버엔지니어링에 빠졌음을 느낄 때 안심하고 다음으로 나아갈 수 있도록 **피드백을 제공**
88+
89+
## 핵심은 피드백
90+
91+
- 테스트 주도 개발의 핵심은 정해진 절차가 아니라 짧은 주기로 지속되는 **피드백**
92+
- 피드백에 기반해 안정적을 지식과 코드를 늘려 나가는 것이 목적

0 commit comments

Comments
 (0)