클린코드 9장

 

주제

• 클린코드 9장 정리

 

---

9장 "단위 테스트" 요약

단위 테스트

# 메모

TDD 법칙

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 

방대한 테스트 케이스를 커버할 수 있지만 그만큼 관리 문제도 야기된다.

 

실제 코드가 진화하면 테스트 코드도 변해야 한다는 문제.

테스트 코드가 지저분하고 복잡할 수록 수정하기도 어렵고 새로운 테스트 케이스를 추가하기도 어렵다.

떄문에 새 버전을 출시할 때마다 팀이 테스트 케이스를 유지하고 보수하는 비용도 늘어난다..

이시간이 많이 드는 문제로 테스트를 포기하는 상황에 처함

 

근데 테스트가 없으면 개발자가 수정/작업한 코드가 제대로 도는지 확인할 방법이 없어 결함율이 높아진다.

개발자가 변경을 주저하게 됨

 

따라서 테스트 코드는 실제 코드 못지 않게 깨끗하게 짜야 한다.

 

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

그 버팀목은 단위 테스트이다. 테스트 케이스가 있으면 변경이 두렵지 않음. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그임.

테스트 케이스가 있으면 변경이 쉬워지고 불안함이 해소된다.

 

깨끗한 테스트 코드 작성 노하우

가독성이 무엇보다 중요함

 

build-operate-check 패턴 테스트구조

테스트 자료 생성 -> 자료 조작 -> 조작 결과 검증

 

이중 표준

테스트 api에 적용하는 표준은 실제 코드에 적용하는 표준과 다르다.

실제 코드만큼 효율적일 필요는 없다.

가독성을 위해 실제 코드와는 다르게 짤 수 있음

 

assert문이 테스트당 하나라면 이해하기 쉽고 빠를 수 있다.

(결론이 하나니까)

 

테스트 함수마다 한 개념만 테스트하는 것이 좋음

 

FIRST 규칙

빠르게 돈다.

서로 의존하지 않는다

  - 테스트가 다음 테스트의 환경을 준비해서는 안 된다.

  - 어느 순서로 실행하든 독립적으로 실행하든 가능해야 함)

  - 서로에 의존하면 연달아 실패함

반복 가능해야 함

자가 검증 테스트는 부울값으로 결과를 내야 한다.

  - 통과 여부를 알려고 파일을 읽게 하거나 뭔가를 비교하게 만들면 안됨. 스스로 판가름

적시에 작성한다.

  - 코드 구현 직전에 만든다.

 

 

 

# 요약

깨끗한 코드를 만들어 관리하기 어려움을 최소화하고, 장점만 극대화 한다.

단위 테스트를 통해 테스트 케이스를 확보하자(변경에 두렵지 않다)

지속적으로 깨끗하게 유지하자