책너두 5기 17일차
로버트 C. 마틴의 클린코드 p.151 ~ p.160
내용 정리
8. 경계
깨끗한 경계
통제하지 못하는 코드를 사용할 때는 과투자나 향후 변경 비용의 과대화를 주의해야 한다.
통제 불가능한 외부 패키지보다 통제 가능한 우리 코드에 의존하는 것이 좋다.
9.단위 테스트
과거의 단위 테스트는 자기 프로그램이 ‘돌아간다’는 사실만 확인하는 일회성 코드였다.
TDD 법칙 세가지
첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
이 규칙을 지키면 개발과 테스트가 짧은 시간내로 묶이게 된다. 그 결과 매일 수 많은 테스트 케이스가 나오게 되고 실제 코드를 사실상 전부 테스트하게 된다. 하지만 너무 방대하면 문제가 생길 수 있다.
깨끗한 테스트 코드 유지하기
‘빨리’를 위해 변수 이름도 신경 쓰지 않고, 테스트 함수가 간결하지도 않아 돌아가기만 하는 테스트 코드를 짜선 안된다. 지저분한 테스트 코드는 안하느니만 못하기 때문이다. 실제 코드가 진화하면 테스트 코드도 변해야 하는데 지저분하면 변경하기 어렵다. 그 결과 테스트 케이스를 추가하는 시간이 실제 코드 작성시간 보다 길어진다.
테스트 슈트가 없으면 수정한 코드가 제대로 작동하는지 확인할 수 없다. 모든 코드를 확인할 수 없으니 결함율이 높아지고 변경을 주저하며 코드가 망가지기 시작한다.
테스트 코드는 실제 코드 못지 않게 중요하다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
테스트 코드를 깨끗하게 유지하지 못하면 잃어버리고, 그 결과 코드를 유연하게 만드는 버팀목도 사라진다. 테스트 케이스가 없을 땐 모든 변경이 잠재적인 버그이기 때문이다. 테스트 케이스가 있어야만 변경이 쉬워진다.
깨끗한 테스트 코드
깨끗한 테스트 코드를 위해 필요한 건 가독성이다. 따라서 명료셩, 단순성, 풍부한 표현력이 필요하다.
읽고 나서
프로젝트를 진행하면서 새로운 기능을 추가하거나 기존 코드를 변경했을 때 전체 코드가 망가져 어디 부분이 잘못됐는지 찾는데 하루 종일, 혹은 몇일을 고생하거나 포기했던 적이 있다. 오늘 읽은 부분에서 다시금 느끼지만 가장 편한 방법은 가장 귀찮아 보이는 방법이다!
