Unit Testing 4장의 내용을 정리한 글입니다.
⭐️ 3장 Remind : 좋은 유닛 테스트는.. ⭐️
- 개발 주기에 통합되어 있다.
- 중요한 부분에 집중한다. (도메인 유의성)
- 최소한의 유지비로 최대 가치를 끌어낸다.
- 3번을 수행하기 위해 가치 있는 테스트를 식별하고, 작성할 수 있어야 한다.
💡 좋은 단위 테스트의 4대 요소 💡
-
회귀 방지
- 회귀(Regression) : 코드 수정 후 기능이 의도한 대로 작동하지 않는 경우
- 회귀 방지 지표:
- 테스트 중에 실행되는 코드의 양
- 코드 복잡도
- 코드의 도메인 유의성
-
리팩토링 내성
- 리팩토링 내성 지표:
False Positive에 주의하자- 거짓 양성 : 문제가 없는데 테스트가 깨지면 발생
- 테스트가 지속가능한 성장을 돕는 것은, 테스트를 통해 회귀 없이 주기적으로 리팩토링 & 신규 기능 추가가 가능함으로부터 뒤따라오는 것이다.
- 거짓 양성이 지속되면,
- 회귀를 피하려고 리팩토링 안하고
- 의지가 떨어져서 테스트를 무시한다
- 그럼 어떡하나?!
테스트 시 최종적으로 의미 있는 결과만 확인하도록 하자 (구현 세부사항 말고)
- 리팩토링 내성 지표:
-
빠른 피드백
- 테스트는 빨라야 한다. (ㄹㅇ... 🥲)
-
유지 보수성
테스트가 얼마나 이해하기 어려운가?
→ 테스트 코드의 품질은 제품 코드만큼 중요하다.테스트가 얼마나 실행하기 어려운가?
→ 외부 의존적으로 작동하는가? 그렇다면 운영이 잘 되고 있는가?
💡 회귀 방지와 리팩토링 내성
False Negative- 회귀방지를 통해 예방 가능
테스트를 잘 짜면, 기능이 의도한 대로 동작하지 않는 경우를 줄일 수 있다.False Positive- 리팩토링 내성을 키워서 예방해야 함
테스트를 "잘" 짜야, 거짓 양성을 최소화하면서 지속 가능한 코드를 만들어나갈 수 있다.
🤔 그렇다면, 이상적인 테스트란 뭘까?
앞선 좋은 테스트의 특성들은 상호 배타적인 관계를 가진다.
- e2e 테스트는 회귀 방지와 리팩토링 내성을 얻고, 속도를 포기해야 한다.
- 간단한 테스트는 회귀 방지에 취약하다 (틀리기 쉽다).
- 깨지기 쉬운 테스트를 짜는 것은 (구현 세부사항을 노출시켜서) 리팩토링 내성을 취약하게 만든다
- (유지 보수성은 다른 3 요소들과 상대적으로 덜 직접적인 관계이다)
- 회귀 방지, 리팩토링 내성, 빠른 피드백
- 모두를 아우를 수 있는 테스트 코드는 이상적이고, 도달할 수가 없다.
- 세 가지 특성을 모두 '어느 정도로'만 만족하도록 짜면 될 노릇일까?
- ❗️ 아니다 ❗️
- 리팩토링 내성은 포기할 수 없음
- 리팩토링 내성은 ‘조금만' 가지고 있을 수 없다. 있거나 없거나 중 하나..
- 이렇게 되면 신경쓸 것은..
- 테스트가 얼마나 버그를 잘 찾아낼 수 있고, 얼마나 빠른지 사이의 절충
- 테스트를 탄탄하게 하려면, 무엇보다도 거짓 양성이 없어야 함
블랙박스 테스트 vs 화이트박스 테스트
화이트박스 테스트를 쓰면, 어쩔 수 없이 구현 세부사항을 노출시킨다.
구현 세부사항이 노출되는 순간 리팩토링 내성은 자연스럽게 사라지게 된다.
그러므로...!
블랙박스 테스트를 작성해라- 도메인 문제 영역에 의미 있는 동작을 확인해라. 리팩토링 내성은 타협할 수 없다. 세부 구현에 집착하지 마라
- 테스트 분석이나, 유틸리티 알고리즘 같이
특수한 케이스들에 대해서만 화이트박스 방법을 사용해라.
프로그래밍은 결국 문제를 해결하기 위한 "일"이지, 예술이나 학문이 아니니까..
과도한 Mocking & 그로 인한 리팩토링 내성 하락은 매우 경계시되어야 하는 것이다.
현실의 문제를 해결하는 것에 집중하자 :)
