<Chapter 2>

• 일부 복잡한 메서드에서는 테스트 코드를 작게는 수십 개 혹은 수백 개 작성 할 수 있다.
• 이때 얼마나 많은 테스트를 작성해야 하는지 생각해 볼 때, 코드에서 분기점이나 잠재적으로 영향력이 큰 데이터 변형들도 고려해 볼 수 있다. (if와 같은 조건문, 반복문, 데이터 변형(null, 0) 고려)
• 테스트를 작성하고 나면 코드가 실제로 어떻게 동작하는지 더 잘 이해할 수 있다.
• 테스트 코드 또한 리펙토링 해야 한다.
• @BeforeEach와 같은 메서드를 통해서 중복된 로직을 제거할 수 있다.
  • 테스트 클래스의 인스턴스 생성 → @BeforeEach 실행 → 테스트 메서드 실행 및 검증 → 테스트 클래스 인스턴스 새로 생성 → …
  • 핵심은 모든 테스트를 독립적으로 만든다. (메서드 마다 각기 다른 인스턴스에서 실행)
  • 따라서 static 필드를 테스트 클래스에서는 피해야 한다. (영향 최소화)
• 테스트를 더 단순하게 작성할 수 있도록 테스트 코드를 정기적으로 정리해야 한다.

<Chapter 3> Junit 단언 깊게 파기

• Junit에서 단언은 테스트에 넣을 수 있는 정적 메서드 호출이다. → 대부분의 프로그래머는 군더더기 줄이고자 static import 사용한다,
• 각 단언은 어떤 조건이 참인지 검증하는 방법이다. (assert)
• 단언한 조건이 참이 아니면 테스트는 그 자리에서 멈추고 실패 (fail)을 보고 한다.
• 책에서는 hamcrest를 사용한 assertion으로 되어 있다
• 테스트 이름은 검증하려는 동작에 관한 일반적인 설명.
• assertThat은 명확한 값을 비교한다.
• assertTrue()는 실패하면 테스트 코드를 분석해 무엇이 문제인지 찾아봐야 한다. 따라서 assertThat을 사용하는것이 실패 지점을 확인하는데 더 명확하다.
• null인지(객체 타입 검사) 확인하는 것은 괜찮지만 null이 아닌 것을 자주 검사하는 것은 설계 문제이거나 지나치게 걱정하는 것이기에 불필요하고 가치가 없다.
• 부동소수점 수를 두개 비교 → 근사치로 구해야 하기 때문에 isCloseTo 를 사용하면 된다. assertThat(2.32 * 3).isCloseTo(6.96, Percentage.withPercentage(0.00005));