[클린코드] 17일차/18일차 - 적시에 빠르고, 독립적이며, 반복가능하여, 자가검증 하는 단위테스트
클린코드 17일차 (p. 151~152(8장) / 153~160(9장) )
클린코드 18일차 (p. 161 ~ 169(9장) )
9장 단위 테스트
꼬치꼬치 따지며 코드가 제대로 도는지 확인하는 테스트 코드를 작성하라.
1. TDD 법칙 세 가지
- TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다.
- TDD 법칙 세가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- 이 방식이면 매일 수십 개의 테스트 케이스가 만들어진다.
- 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발한다.
2. 깨끗한 테스트 코드 유지하기
- 일회용 테스트 코드를 짜다가 자동화된 단위 테스트를 짜기란 쉽지 않다.
- 테스트 코드는 실제 코드 못지 않게 중요하며, 실제 코드 못지 않게 깨끗하게 짜야한다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트이다.
- 실제 코드를 점검하는 자동화된 단위 테스트는 설계와 아키텍처를 깔끔하게 보존하는 열쇠이다.
3. 깨끗한 테스트 코드
깨끗한 테스트 코드를 만들려면 ?
- 1. 가독성 / 2. 가독성 / 3. 가독성
- 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.
가독성을 높이려면 ?
- 명료성, 단순성, 풍부한 표현력이 필요하다.
4. 테스트 당 assert 하나
- JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용해야 한다는 주장하는 학파가 있다..
- 가혹한 규칙이라 여길지 몰라도 확실히 장점이 있다!
- assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
- 하지만 assert 문이 여럿이라는 사실은 문제가 아니다.
- 한 테스트 함수에서 여러 개념을 테스트한다는 사실이 문제다.
- 가장 좋은 규칙은 "개념 당 assert 문 수를 최소로 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"이다.
5. F.I.R.S.T
- 빠르게 First
- 테스트는 빨라야 한다//
- 즉, 빨리 돌아야 한다.
- 독립적으로 Independent
- 각 테스트는 서로 의존하면 안 된다.
- 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다.
- 반복가능하게 Repeatable
- 테스트는 어떤 환경에서도 반복 가능해야 한다.
- 실제 환경, QA 환경, 버스를 타고 집으로 가는 길에 사용하는 노트북 환경에서까지도 실행 가능해야한다..
- 자가검증하는 Self-Validating
- 테스트는 부울bool 값으로 결과를 내야한다.
- 즉, 성공 아니면 실패이다!
- 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다..!!
- 적시에 Timely
- 테스트는 적시에 작성해야한다.
- 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
'알아두면쓸데있는신기한잡학사전 > 독서일지' 카테고리의 다른 글
[클린코드] 20일차 - 변경하기 쉬운 클래스 == SRP, OCP 준수 (0) | 2023.11.16 |
---|---|
[클린코드] 19일차 - 클래스는 작게 그리고 하나의 책임만 줘라 (2) | 2023.11.13 |
[클린코드] 16일차 - 소프트웨어 경계를 깔끔하게 처리하는 기법 (2) | 2023.11.12 |
[클린코드] 15일차 - 오류 처리 (부제: 프로그램 논리와 분리해 독자적인 사안으로 고려) (1) | 2023.11.10 |
[클린코드] 14일차 - 객체(자료숨김), 자료구조(자료공개) (1) | 2023.11.08 |