9장.단위테스트

❤️ TDD 법칙

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

❤️ 테스트코드의 장점

• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 단위테스트 이다
  -> 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다
• 실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다
• 테스트 케이스가 있으면 변경이 쉬워진다

❤️ 깨끗한 테스트 코드란?

★ 깨끗한 테스트 코드는 가독성이 가장 중요하다.

• 각 테스트 코드는 세 부분으로 나누어진다
  1 ) 첫부분 : 테스트 자료를 만든다
  2) 두번째 : 테스트 자료를 조작한다
  3) 세번째 : 조작한 결과가 올바른지 확인한다
• 테스트당 assert 는 하나만 사용해야 한다 -> 결론이 하나이기 때문에 코드를 이해하기 쉽고 빠르다
• 테스트 함수마다 한 개념만 테스트해야 한다

❤️ F.I.R.S.T 규칙

• F (Fast) : 빠르게 -> 테스트는 빨라야 한다
• I (Independent) : 독립적으로 -> 테스트는 서로 의존하면 안된다. 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패해 원인을 진단하기 어려워지며 후반 테스트가 찾아내야 할 결함이 숨겨진다
• R (Repeatable) : 반복가능하게 -> 테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이류를 둘러댈 변경이 생긴다
• S (Self-Validating) : 자가검증하는 -> 테스트는 boolean 값으로 결과를 내야한다. 테스트가 스스로 성광과 실패를 가능하지 않는다면 판단은 주관적으로 되며 지루한 수작업 평가가 필요하게 된다
• T (Timely) : 적시에 -> 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다

‼️ 나의생각

SpringBoot 프로젝트 공부할 때 귀찮게 왜 테스트 코드를 자꾸 작성하라고 하는걸까? 라는 생각을 한 적이 있다. 그냥 프로그램을 실행 해 확인하면 된다고 생각했다. 하지만 이미 배포 된 프로그램이라면 이러한 방법이 효율적이지 않고 아주 위험한 방법이라는 것을 느꼈다. 책을 읽고 보니 테스트 코드를 잘 작성해 두면 담당자가 바뀌어도 테스트 코드를 보고 메서드의 역할을 쉽게 파악 할 수 있고 코드의 변경이 일어났을 때에도 빠르고 쉽게 결과를 확인할 수 있다는 것을 알았다. 시간이 조금 소요되더라도 테스트 코드를 작성하도록 습관을 들여봐야겠다.