프로그램을 작성하고, 제대로 된 테스트 케이스를 작성해야 한다.🪡

TDD 법칙 세가지

TDD(Test Driven Development)
: 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스
작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

단위 테스트
: 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트

깨끗한 테스트 코드 유지하기

테스트 케이스 코드가 너무 복잡하면 실제 코드를 변경하기 어려워진다. 기존 테스트 케이스 코드를 통과하기 위해 코드가 더러워진다.💩
그렇다고 테스트 케이스를 아예 없애면 개발자는 자신이 수정한 코드가 제대로 작동하는지 확인할 방법이 없다.
-> dilemma☠️

테스트 코드를 실제 코드 못지 않게 깨끗하게 짜야 한다.

테스트는 유연성, 유지보수성, 재사용성을 제공한다

깨끗한 테스트 코드

테스트 코드에서는 실제 코드보다 가독성이 더욱 중요하다.
: 명료성, 단순성, 풍부한 표현력이 필요하다. 최소의 표현으로 많은 것을 나타내야 한다.

도메인에 특화된 테스트 언어

: DSL
프로그래머와 해당 분야의 전문가를 연결해주는데 큰 도움을 준다. 대상 분야에 능통한 비 프로그래머가 사용하도록 제작되었다.
-> 테스트를 구현하는 당사자와. 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어

이중 표준

실제 코드와 테스트 코드에 적용하는 표준은 다르다.
실제 환경에서는 안되지만 테스트 환경에서는 가능한 방식이 있다. 성능보다는 가독성에 힘을 쓰는 것이 낫다.

테스트 당 assert 하나

테스트 당 개념 하나

여러 테스트 개념을 한 함수에 넣으면 모든 개념을 사용자가 이해해야 하기 때문에 분리하는 것이 좋다.

F.I.R.S.T

깨끗한 코드는 아래의 다섯 가지 규칙을 따른다.

1. 빠르게(Fast)
   : 테스트는 빠르게 작동해야 한다.
2. 독립적으로(Independent)
   : 각각의 테스트는 서로 의존하면 안 된다. 테스트의 실패 원인을 찾기 어려워진다.
3. 반복가능하게(Repeatable)
   : 어느 환경에서나 테스트를 반복 할 수 있어야 한다.
4. 자가검증하는(Self-Validating)
   : 테스트는 불 값으로 결과를 내야 한다.
5. 적시에(Timely)
   : 테스트는 적절한 시간에 작성되어야 한다. 실제 코드를 구현한 이후에 작성하면 테스트를 하기 어려워진다.