diff --git a/content/books/cleancode/9.md b/content/books/cleancode/9.md
new file mode 100644
index 0000000..f56523e
--- /dev/null
+++ b/content/books/cleancode/9.md
@@ -0,0 +1,176 @@
+---
+title: '9장. 단위 테스트'
+metaTitle: '만렙 개발자 키우기'
+order: 8
+tags: ['Book']
+date: '2022-04-27'
+---
+
+## TDD 법칙 세 가지
+
+1. 실패하는 단위 테스트를 작성할 때까지 실제 코드 작성하지 않기
+
+2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성
+
+3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성
+
+
+이렇게 일하면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다.
+
+하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.
+
+---
+
+## 깨끗한 테스트 코드 유지하기
+
+지저분한 테스트 코드를 내놓는 것은 테스트를 안하는 것과 같다. 오히려 더 못하다!
+
+실제 코드가 진화하면 테스트 코드도 같이 변해야 하는데, 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리게 된다.
+
+실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다.
+
+따라서 테스트 코드는 계속해서 늘어나는 부담이 된다.
+
+그리고 새 버전 출시마다 테스트 케이스를 유지하고 보수하는 비용도 늘어난다.
+
+그러나 **테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.**
+
+-> 결함율 높아짐
+
+-> 개발자가 변경을 주저하게 됨
+
+-> 더 이상 코드가 정리되지 않음
+
+-> 코드가 망가지기 시작!!
+
+테스트 코드를 깨끗하게 짜서 이러한 상황이 발생하지 않도록 하자.
+
+테스트 코드가 지저분할수록 실제 코드도 지저분해진다.
+
+---
+
+## 깨끗한 테스트 코드
+
+테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다.
+
+단위 테스트는 코드에 `유연성`, `유지보수성`, `재사용성` 을 제공하는 버팀목이 된다.
+
+**테스트 코드가 없으면 모든 변경이 잠정적인 버그다.**
+
+테스트 코드가 있으면 변경이 두렵지 않게 된다! 아키텍처가 부실한 코드나 설계가 모호하고 엉망인 코드라도 별다른 우려없이 안심하고 아키텍처와 설계를 개선할 수 있다.
+
+그렇다면 깨끗한 테스트 코드를 어떻게 만드는가?
+
+가장 중요한 것이 바로 `가독성`이다.
+
+테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. with `명료성`, `단순성`, `풍부한 표현`
+
+테스트와 무관한 코드는 테스트 코드의 의도만 흐린다. 그러므로 잡다하고 세세한 코드는 없애고, 진짜 필요한 자료 유형과 함수만 사용한다.
+
+> `BUILD-OPERATE-CHECK` 패턴
+>
+> 1. 테스트 자료 만들기 (Given)
+>
+> 2. 테스트 자료 조작하기 (When)
+>
+> 3. 조작한 결과가 올바른지 확인하기 (Then)
+
+### 도메인 특화 테스트 언어
+
+시스템 조작 API 를 사용하는 대신 API 위에다 함수와 유틸리티를 구현. 그리고 그 함수와 유틸리티를 사용한다. -> 테스트 코드에서 사용하는 특수 API
+
+당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어.
+
+### 이중 표준
+
+테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 다르다.
+
+**단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제코드만큼 효율적일 필요는 없다.**
+
+실제 환경이 아니라, 테스트 환경에서 돌아가는 코드이기 때문!
+
+이중 표준의 본질은 실제 환경에서는 절대로 안 되지만, 테스트 환경에서는 전혀 문제없는 방식이 존재한다는 것
+
+대개 메모리나 CPU 효율과 관련 있는 경우로, 코드의 깨끗함과는 철저히 무관하다. (책에선 StringBuffer 대신 보기 좋은 String 을 사용하는 예시를 들었음)
+
+---
+
+## 테스트 당 assert 문 개수는 최소로 작성
+
+assert 문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
+
+만약 하나로 병합하는 방식이 불합리한 경우에는 테스트를 두 개로 쪼개서 각자가 assert 를 수행하면 된다.
+
+함수 이름에 `given-when-then` 이라는 관례를 사용하면 테스트 코드를 읽기가 쉬워지는데, 그렇게 테스트를 분리하면 중복되는 코드가 많아진다.
+
+이러한 중복은 다음과 같이 제거할 수 있다.
+
+- `TEMPLATE METHOD` 를 사용
+
+- given/when 부분을 부모 클래스에, then 부분을 자식 클레스에 두기
+
+- 독자적인 테스트 클래스를 만들어 `@Before` 함수에 given/when, `@Test` 함수에 then
+
+하지만 이런 저런 상황들이 추가로 발생하다보니, 그냥 assert 문을 여럿 사용하는 편이 좋다.
+
+`단일 assert 문` 이라는 규칙이 훌륭한 지침이지만, 때로는 함수 하나에 여러 assert 문을 넣는 것이 좋은 경우도 있다.
+
+단지 assert 문 개수는 최대한 줄이는 것이 좋다.
+
+### 테스트 당 개념 하나
+
+테스트 함수마다 한 개념만 테스트하라는 규칙이 더 낫다.
+
+잡다한 개념을 연속으로 테스트하는 긴 함수는 피하자. 그렇지 않으면 독자가 각 절이 거기에 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다.
+
+---
+
+## FIRST 규칙
+
+### Fast
+
+> 테스트는 빨라야 한다.
+
+테스트가 느리면 자주 돌릴 엄두를 못 내고, 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다. 또한 코드를 마음껏 정리하지도 못하여 결국 코드 품질이 망가지기 시작한다.
+
+### Independent
+
+> 각 테스트는 서로 의존하면 안 된다.
+
+각 테스트는 독립적으로, 그리고 어떤 순서로 실행해도 괜찮아야 한다.
+
+서로 의존하는 테스트 코드는 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어렵고, 후반 테스트가 찾아내야 할 결함이 숨겨진다.
+
+### Repeatable
+
+> 테스트는 어떤 환경에서도 반복 가능해야 한다.
+
+### Self-Validating
+
+> 테스트는 bool 값으로 결과를 내야 한다.
+
+성공 or 실패 -> 테스트가 스스로 성공과 실패를 가늠하지 않으면 판단은 주관적이 되며, 지루한 수작업 평가가 필요해짐
+
+### Timely
+
+> 테스트는 적시에 작성해야 한다.
+
+실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.
+
+또는 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.
+
+따라서 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
+
+---
+
+## 결론
+
+테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하며, 어쩌면 실제 코드보다 더 중요할 수도 있다.
+
+테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존/강화 한다.
+
+따라서 지속적으로 테스트 코드를 깨끗하게 관리하고, 표현력을 높이고, 간결하게 정리하자.
+
+테스트 API 를 구현해 도메인 특화 언어를 만들어서 사용하면 테스트 코드를 짜기가 쉬워진다!
+
+테스트 코드가 방치되어 망가지면 실제 코드도 망가진다 !!!