8장 2줄 요약 (나머지는 9장 내용)

• 제3자 코드를 사용할 때는 그 코드와 우리 코드 사이의 경계를 명확히 관리해야 하며, 이를 위해 적절한 테스트와 인터페이스 분리를 해야 한다.
• 학습 테스트를 작성함으로써 제3자 코드의 동작을 검증하고 이해를 증진시키며, API가 변경될 경우 이에 빠르게 대응할 수 있는 구조를 만든다.

  솔직히 뭔 소린지 잘 모르겠다.

TDD법칙 세가지

TDD: Test Driven Development

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

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

지저분한 테스트 코드를 쓸 바에는 테스틀 안하는게 낫다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸린다.

테스트 코드는 실제 코드 못지 않게 중요하다

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

테스트 케이스가 있으면 변경이 두렵지 않으니까!
테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다.
가독성, 가독성, 가독성
-> 참고로 난 이런 말장난 싫어한다

가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.

Java 예제들은.. 이번엔 생략한다.

테스트당 assert 하나

JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 하나만 사용해야 한다고 주장하는 사람들이 있다. assert문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.

JUnit은 Java에서 Unit테스트를 할 수 있게 해주는 패키지이다.
Dart에서는 test 패키지가 있다.

F.I.R.S.T

깨끗한 테스트는 다음 다섯 가지 규칙을 따른다

• Fast: 테스트는 빨라야 한다. 느리게 돌아가면 자주 못돌린다.
• Independent: 각 테스트는 서로 의존하면 안된다. 어떤 순서로 실행해도 괜찮아야 한다.
• Repeatable: 테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA환경, 네트워크가 있건 없건 실행 가능해야 한다.
• Self-Validating: 테스트는 bool값으로 결과를 내야 한다. 성공 아니면 실패다. 통과 여부를 알기 위해 로그 파일을 읽게하면 안된다.
• Timely: 테스트는 적시에 작성해야 한다.