# TDD

TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다.

테스트 주도 개발에서는 다음 두 가지 단순한 규칙만 따른다.

* **오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.**
* **중복을 제거한다.**

테스트 주도 개발의 간략한 과정은 다음과 같이 요약할 수 있다.

1. 재빨리 테스트 하나 추가한다.
2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
3. 코드를 조금 바꾼다.
4. 모든 테스트를 실행하고 전부 성공하는지 확인한다.
5. 리팩토링을 통해 중복을 제거한다.

이 과정을 거치면서 아래 내용들을 경험할 수 있을 것이다.

* 각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지
* 새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지
* 얼마나 자주 테스트를 실행하는지
* 얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지

## 의존성과 중복

스티브 프리만(Steve Freeman)은 테스트와 코드 간의 문제는 중복이 아니라 테스트와 코드 사이에 존재하는 의존성이라고 말했다. 즉, 코드나 테스트 중 한쪽을 수정하면 반드시 다른 한쪽도 수정해야만 한다는 것이다. 의존성은 소프트웨어 개발의 모든 부분에서 핵심적인 문제이다.

의존성이 문제 그 자체라면, 중복은 문제의 징후이다. 중복의 가장 흔한 예는 로직 중복이며, 중복된 로직을 하나로 합치는데는 객체를 이용하는 것이 제일 좋다.

문제 자체는 남겨둔 채로 징후만을 제거하면 프로그램에서는 의존성도 제거된다. 이게 바로 TDD의 **"중복을 제거한다."** 두번째 규칙이 존재하는 이유이며, 다음 테스트로 진행하기전에 중복을 제거함으로 오직 한기지의 코드 수정을 통해 다음 테스트도 통과되게 만들 가능성을 최대화 하는 것이다.

## 일반적인 TDD 주기

1. 빨강 : 실패하는 작은 테스트를 작성
   * 테스트를 작성한다. 이때 올바른 답을 찾기 위해서 필요한 모든 요소를 포함시켜야한다.
2. 초록: 빨리 테스트가 통과하게끔 작성. 이를 위해서 기존코드 복붙, 테스트만 통과하도록 특정 상수 반환 함수 구현 등과 같이 구현해도 된다.
   * 실행 가능하게 만든다. 최대한 초록 막대(테스트 통과)를 볼 수 있게 하는 것이 가장 중요하다.
   * 접근법
     1. 가짜로 구현하기 : 상수를 반환하게 만들고 진짜 코드를 얻을 때까지 단계적으로 상수를 변수로 바꾼다.
     2. 삼각측량법(5 == 5, 5 != 6) : 어떻게 테스트를 구현해야할지 모를 때 작성
     3. 명백한 구현 사용하기 : 실제 구현을 입력한다.
3. 리팩토링 : 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복 제거
   * 올바르게 구현한다. 이때 중복을 제거하고, 테스트를 통과하기 위해 막 개발했던 코드를 수정한다.

## 3A 패턴

테스트 작성시 공통된 패턴을 발견하게 된다.

1. 준비(arrange) : 객체 생성
2. 행동(act) : 어떤 자극을 준다.
3. 확인(assert) : 결과를 검사한다.

행동과 확인 단계는 매번 다르지만 준비 단계는 여러 테스트가 동일한 경우가 있다.

> 테스트를 위해서 새로운 객체를 얼마나 자주 생성해야될까?

이때 두가지 제약이 상충한다.

* 성능 : 여러 테스트에서 같은 객체를 사용한다면, 객체 하나만 생성해 모든 테스트가 이 객체를 사용하도록 한다.
* 격리 : 하나의 테스트에서 성공/실패가 다른 테스트에 영향을 주지 않기를 원한다. 테스트 객체를 공유하는 상태에서는 한개의 테스트의 결과가 다른 테스트의 결과에 영향을 미칠 확률이 높다.

테스트 사이의 커플링은 확실히 지저분한 결과를 만들며, 한 개의 테스트 결과가 다른 테스트 결과에 영향을 미칠 수도 있다. 그러므로 테스트 커플링은 만들면 안된다.

테스트를 격리하기 위해서는 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 구성되게 해야한다.

## 테스트 주도 개발 패턴

### 테스트 우선

* 테스트는 테스트목록을 모두 작성한 뒤 구현하자.
  1. 구현할 필요가 있는 모든 오퍼레이션의 사용 예를 작성
  2. 존재하지 않는 오퍼레이션에 대해서는 null버전을 리스트에 추가
  3. 리팩토링 목록추가
* 테스트는 테스트 대상이 되는 코드를 구현하기 직전에 작성하는 것이 좋다.

### 단언(Assert) 우선

테스트 작성시 단언을 제일 먼저 쓰고 시작하자.

1. 완료된 시스템이 어떨지에 대한 내용부터 작성
2. 기능이 완료되면 통과할 수 있는 테스트 부터 작성
3. 완료될 때 통과해야 할 단언부터 작성

### 테스트 데이터

테스트 데이터는 테스트를 읽을 때 쉽고 따라가기 좋은 데이터를 사용해야한다. 테스트 데이터에 대한 대안은 실제 데이터를 사용하는 것이다.

* 실제 실행을 통해 외부 이벤트 결과를 이용하여 실시간 시스템을 테스트 하는 경우
* 이전 시스템의 출력과 현재 시스템의 출력을 비교하고자 하는 경우 (병렬)
* 시뮬레이션 시스템을 리팩토링한 후 기존과 정확히 동일한 결과가 나오는지 확인하고자 할 경우

위의 경우에 실제 데이터를 사용하면 유용하다.

#### 명백한 데이터

테스트의 의도를 표현하기 위해서 테스트 자체에 예상되는 값과 실제 값을 포함하고, 둘 사이의 관계를 나타내야한다.

다른 통화로 환전하는데 있어서 수수료가 1.5%가 붙는다. USD에서 GBP로 교환하는 환율이 2:1이라면 $100달러를 환전하려면 50GBP - 1.5% = 49.25GBP여야한다.

```java
Bank bank = new Bank();
bank.addRate("USD", "GBP", STANDARD_RATE);
bank.commission(STANDARD_COMMISSION);
Money result = bank.convert(new Note(100, "USD"), "GBP");
assertEquals(new Note(49.25, "GBP"), result);
```

계산을 더 명확히 표현하면 다음과 같다. 위의 예제 보다도 계산을 더 명확히 기입하면 테스트에서 입력으로 사용된 숫자와 결과 사이의 관계를 읽어낼 수 있으며, 다음으로 할 일을 더 쉽게 알 ㅅ ㅜ있다.

```java
Bank bank = new Bank();
bank.addRate("USD", "GBP", 2);
bank.commission(0.015);
Money result = bank.convert(new Note(100, "USD"), "GBP");
assertEquals(new Note(100/2*(1-0.015), "GBP"), result);
```

### 아는 것에서 모르는 것으로

작성한 테스트 목록 중에서 아는 것부터 모르는 것으로 테스트 하는 것이 좋다.

뭘 구현해야될지 알면, 명백한 구현을 하고, 잘 모르겠다면 가짜 구현을 하면 된다.

### 모의 객체

모의 객체(Mock Object)를 사용하여 테스트시 실제 객체와 동일한 모의 객체를 만들어 테스트 효용성을 높이기 위해 사용한다.

> **모의 객체**(Mock Object)란 주로 [객체 지향 프로그래밍](https://ko.wikipedia.org/wiki/%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D)으로 개발한 프로그램을 테스트 할 경우 테스트를 수행할 모듈과 연결되는 외부의 다른 서비스나 모듈들을 실제 사용하는 모듈을 사용하지 않고 **실제의 모듈을 "흉내"내는 "가짜" 모듈을 작성하여 테스트의 효용성을 높이는데 사용하는 객체**이다.
>
> [*위키 백과-모의 객체*](https://ko.wikipedia.org/wiki/%EB%AA%A8%EC%9D%98_%EA%B0%9D%EC%B2%B4)

모의 객체는 모든 객체의 가시성에 대해 고려하도록 만들어, 설계에서 커플링이 감소하도록 한다.

## Code Coverage

> **코드 커버리지**(Code Coverage)는 [소프트웨어](https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)의 **테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표중 하나**다. 말 그대로 코드가 얼마나 커버되었는가이다. 소프트웨어 테스트를 진행했을 때 **코드 자체가 얼마나 실행되었냐는 것**이다.
>
> 코드의 구조를 이루는 것은 크게 구문(Statement), 조건(Condition), 결정(Decision)이다. 이러한 구조를 얼마나 커버했느냐에 따라 코드커버리지의 측정기준은 나뉘게 된다. 일반적으로 많이 사용되는 커버리지는 **구문(Statement)커버리지**이며, **실행 코드라인이 한번 이상 실행 되면 충족**된다. **조건(Condition)커버리지는 각 내부 조건이 참 혹은 거짓을 가지면 충족**된다. **결정(Decision) 커버리지는 각 분기의 내부 조건자체가 아닌 이러한 조건으로 인해 전체 결과가 참 혹은 거짓이면 충족**된다. 그리고 조건과 결정을 복합적으로 고려하는 MC/DC 커버리지 또한 있다. - [위키백과 코드 커버리지](https://ko.wikipedia.org/wiki/%EC%BD%94%EB%93%9C_%EC%BB%A4%EB%B2%84%EB%A6%AC%EC%A7%80)

### 측정 기준

코드 커버리지는 소스 코드를 기반으로 수행하는 화이트 박스 테스트를 통해 측정한다.

> **화이트 박스 테스트(White-box test)**
>
> * 응용 프로그램의 **내부 구조와 동작을 검사**하는 테스트 방식
> * 소프트웨어 **내부 소스 코드를 테스트**하는 기법
> * **개발자 관점**의 단위 테스트 방법

#### 구문(Statement)

구문 커버리지는 라인(Line) 커버리지라고 부르기도 하며, **코드 한 줄이 한 번 이상 실행되면 충족**한다.

```java
    void statement(int x) {
        System.out.println("start line"); // (1)
        if (x > 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }
```

여기서 `x = -1` 로 테스트를 진행하게 되면 (3)코드는 실행되지 않는다. 총 4개의 라인 중 1, 2, 4만 수행되므로 75%가 된다.

구문 커버리지가 가장 대표적으로 많이 사용되고 있다.

#### 조건(Condition)

**모든 조건식의 내부 조건이 true/false를 가지면 충족**한다.

```java
	void condition(int x, int y) {
        System.out.println("start line"); // (1)
        if (x > 0 && y < 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }
```

조건 커버리지를 만족하는 테스트 케이스는 `x = 1, y = 1`, `x = -1, y = -1` 이 있다.

* `x > 0` 조건 : true/false
* `y < 0` 조건 : false/true

조건 커버리지는 만족하지만 if문 조건은 항상 false이므로 (3) 코드는 실행되지 않는다.

조건 커버리지를 기준으로 테스트한 경우, 구문 커버리지와 결정 커버리지를 만족하지 못하는 경우가 존재할 수 있다.

#### 결정(Decision)

결정 커버리지는 브랜치(Branch) 커버리지라고도 하며, 모든 조건식이 true/false를 가지게 되면 충족한다.

```java
	void condition(int x, int y) {
        System.out.println("start line"); // (1)
        if (x > 0 && y < 0) { // (2)
            System.out.println("middle line"); // (3)
        }
        System.out.println("last line"); // (4)
    }
```

결정 커버리지를 만족하는 테스트 케이스는 `x = 1, y = -1`, `x = -1, y = 1` 이 있다.

* `x > 0`, `y < 0` 모두 만족 : true
* `x > 0`, `y < 0` 불충족 : false

조건/결정 커버리지는 코드 실행에 대한 테스트보다 로직 시나리오에 대한 테스트에 더 가깝다고 볼 수 있으며, 두 커버리지는 조건에 대해 모두 만족하면 코드 커버리지를 만족한다고 본다. 또한 조건문이 존재하지 않는 코드의 경우 두 커버리지 대상에서 아예 테스트 대상에서 제외 된다.

코드 커버리지 도구와 소나큐브(SonarQube) 정적 코드 분석 도구를 함께 사용해 코드 커버리지가 기존보다 떨어지는 경우 커밋이 불가능하도록 제한하기도 한다.

## 참고

* [테스트 주도 개발](https://book.naver.com/bookdb/book_detail.nhn?bid=7443642)
* [lxxjn0.log](https://velog.io/@lxxjn0)