[클린코드]9.단위 테스트

《클린코드》에서는 테스트를 매우 중요하다고 말한다. 꼭 이 책 뿐만 아니라 TDD의 중요성에 대해서는 익히 들어서 알고 있다. 그러나 현재 맡고 있는 업무의 시스템에 테스트 코드가 전혀 존재하지 않는다. 자연스럽게 나도 테스트를 기반으로 프로그램을 짜는 것에 익숙하지 않다.
개인적으로 개발하는 건들에 대해서라도 테스트 코드를 작성하는 연습을 해야겠다. 물론 개인적으로 만드는 프로그램들은 빠르게 만드는 것에 집중하기 때문에 테스트에 시간을 많이 쓰는 것이 꺼려지기도 하지만, 개인 공부를 위해서라도 습관을 들여야겠다.

📆TIL(Today I Learned) 날짜

2022.04.13

📑오늘 읽은 범위

9.단위 테스트

✍🏻책에서 기억하고 싶은 내용

애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다.

TDD 법칙 세 가지
👉🏻첫째 법칙 : 실패하는 단위 테스트를 작성할 떄까지 실제 코드를 작성하지 않는다.
👉🏻둘쨰 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
👉🏻셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

테스트 코드는 실제코드 못지 않게 중요하다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.

아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다. 하지만 테스트 케이스가 있다면 공포는 사실상 사라진다. 테스트 커버리지가 높을수록 공포는 줄어든다. 아키텍처가 부실한 코드나 설계가 모호하고 엉망인 코드라도 별다른 우려 없이 변경할 수 있다. 아니, 오히려 안심하고 아키텍처와 설계를 개선할 수 있다.

테스트 당 assert 하나
나는 ‘단일 assert문’이라는 규칙이 훌륭한 지침이라 생각한다.

테스트 당 개념 하나
어쩌면 “테스트 함수마다 한 개념만 테스트하라”는 규칙이 더 낫겠다. 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.

F.I.R.S.T : 꺠끗한 테스트는 다음 다섯 가지 규칙을 따른다.
👉🏻빠르게(Fast) : 테스트는 빨라야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
👉🏻독립적으로(Independent) : 각 테스트는 서로 의존하면 안 된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
👉🏻반복가능하게(Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
👉🏻자가검증하는(Self-Validating) : 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다.
👉🏻적시에(Timely) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

❓궁금한 내용, 잘 이해되지 않는 내용

• 없음