|
| 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