---
# System prepended metadata

title: 'The RED : 이규원의 현실 세상의 TDD - 테스트 주도 개발 기초'
tags: [석기]

---

The RED : 이규원의 현실 세상의 TDD - 테스트 주도 개발 기초
===

###### tags: `석기`

---

## 코드 기능 명세

### 도메인이란?

소프트웨어는 문제를 푸는 도구.

**소프트웨어가 풀어야 할 문제가 정의되는 공간**

#### 비즈니스 전문가

- 문제를 가장 잘 이해
- 문제 설명력 부족
- 풀이도 가장 잘 이해한다고 **착각**

#### 분석가

- 비즈니스 전문가로부터 시스템 요구사항 발굴
- 해당 요구사항이 어떤 방향성을 가지는지 / 가능한지 판단.

#### 프로그래머

- 정제된 기능 명세를 아키텍처와 코드로 번역
- 끊임없는 설계 결정
- 지식 흐름과정의 마지막 인간

### 컴퓨터

- 코드를 토해 프로그래머로부터 지식을 받음
- 로우 레벨.

### 단위 테스트 작성 실습

#### 분산을 계산하는 프로그램.

- 데이터가 없을때
- 데이터가 하나만 있을때

>[color=#57e5ae] 버그 발생.

---

## 테스트 기법

### 수동 테스트

- 품질 담당자가 UI를 사용하여 기능을 검증
- 최종 사용자의 사용 경험과 가장 비슷하게 검증
- 실행 비용이 높고 결과의 변동이 큼
- 가장 온전한 코드 실행
- 인수 테스트

#### 소프트웨어 회귀

- 특정 이벤트 후에 갑자기 소프트웨어에 버그가 생기는 것

### 테스트 자동화

- 기능을 검증하는 코드 작성
- 실행 비용이 낮고 결과의 신뢰도가 높음
- 프로그래머 역량에 크게 영향을 받음.

### 인수 테스트

- 배치된 시스템을 대상으로 검증.
- 전체 시스템 이상 여부 신뢰도가 높음
- 높은 비용
- 피드백 품질이 낮음

### 단위 테스트

- 시스템의 일부를 대상으로 검증
- 낮은 비용
- 높은 피드백 품질
- 전체 시스템 이상 여부 신뢰도가 낮음

---

## 코드 분해

- 왜 개발자들이 코드를 분해할까?

### 코드 재사용

- 반복되는 문제의 풀이는 재사용 가능
- 소프트웨어 개발 비용 절감

### 모듈화

#### 분해

- 큰 시스템은 작은 하위로 분해
- 교체 가능

#### 조립

- 작은시스템은 큰 시스템으로 조립
- 모듈 재사용
- 라이브러리

---

## 단위 테스트

- 전체 시스템의 일부를 테스트하는 기법.

**Jest**를 활용하여 테스트 진행.

==parameterized test==

---

## 테스트 우선 개발

### 테스트 코드를 운영코드보다 먼저 작성하는 기법.

- 명확하고 검증 가능한 목표를 설정한 후 목표를 설정.
- 프로세스가 코딩에 앞선 목표 설정을 강요
- 프로그래머는 자신이 풀어야할 문제를 구체적으로 이해하여야 함.

---

## 정리된 코드

### Refactoring?

- 의미를 유지하며 코드 베이스를 정리.

- 모듈화 / 로컬 함수로 분리
- 반복된 작업 함수로 분히

---

## 테스트 주도 개발

### 테스트 주도 개발 절차

1. RED 

- 실패하는 테스트 추가
    - 구체적인 하나의 요구사항을 검증하는 하나의 테스트 추가
    - 추가된 테스트가 실패하는지 확인
        - 이때 실패의 요인은 운영 코드의 오류여야함.
2. GREEN

- 테스트 통과
    - 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영코드 변겅
- 최소한의 코딩
    - 가장 중요한 임무를 가장 빠르게 변경

3. BLUE

- 리팩토링
    - 코드 베이스 정리
    - 구현 설계 개선
        - 가독성
        - 적응성
        - 성능
    - 모든 테스트 성공을 전제

### 테스트 주도 개발 세부 흐름

<img width="941" alt="image" src="https://user-images.githubusercontent.com/52649378/162987483-e987136d-fd1b-48b1-8e04-5434ab896ec8.png">

### 테스트 주도 개발은 낯설지 않다.

### 테스트 주도 개발의 비용

- TDD를 사용하지 않는다면
    - 시작할 땐 공수가 낮지만
    - 시간이 흐르면 공수가 더 들어간다.
- TDD를 사용한다면
    - 시작할 땐 공수가 높지만
    - 유지보수가 원활하다.

---

## 프로그래머 피드백

#### 오버 엔지니어링

- 프로그래머는 달성에 목표를 두고 
- 구현 설계 품질 개선에 빠져드는 경향을 가짐.
- 이 속성이 지나친다면 **불필요하게 자원을 낭비하게 됨**
- TDD는 가장 중요한 목표를 우선 달성하도록 유도.
    - 오버엔지니어링에 빠졌음을 느낄때 안심하고 다음으로 나아갈 수 있도록 **피드백을 제공.**

### 핵심은 피드백!

- TDD의 핵심은 정해진 절차가 아니라,
- **짧은 주기로 지속되는 피드백**이다.
- ==피드백에 기반해 안정적으로 지식과 코드를 늘려 나가는 것이 목적.==