[3주 완독 Daily 서평] 클린코드 - 8

이건우·2022년 5월 9일

개발자 노개북 코딩 클린코드

책 서평 시리즈

목록 보기

19/20

#개발자, #노개북, #코딩, #클린코드

8. 경계 & 단위 테스트

이번장은 챌린지 특성한 한 단위로 묶어 적게 되었다. 다른때 보다 간략히, 느낀점 핵심 부분만 (읽었을때) 적어 올리기로 한다.

경계

시스템에 들어가는 모든 소프트웨어를 개발하는 경우는 드물다. 외부코드를 사용하면 적은 시간에 더 많은 기능을 출시하기 쉬워진다. 그래서 우리는 어떤식 으로든 외부 코드를 우리 코드에 맞게끔 깔끔히 통합해야한다. 이번 장에선 깔끔하게 처리하는 기법과 기교를 살핀다.

타사 라이브러리를 가져온뒤 , 공식문서를 읽어가며 사용법을 배운다.
우리쪽 코드를 작성해 라이브러리가 예상대로 동작하는지 확인한다.

(우리 버그인지, 라이브러리 버그인지 찾아낼 수도 있다. 정말 골치아프다.)

사실 외부코드를 익히긴 매우 어려우며, 통합하기도 어렵다. 이 두가지를 동시에 하기엔 더더욱 어렵다. 책에선 '우리쪽 코드를 작성해 외부코드를 호출'하기 보다 '간단한 테스트 케이스'를 통하여 외부코드를 학습하는것을 권장한다.

깨끗한 경계란 변경하는데 많은 투자와 재작업이 필요하지 않다. 시작과 노력으로 재작업을 요구하지 않는것이다. 통과하지 않는 코드에 너무 많은 투자를 하거나 향후 변경 비용이 지나치게 커지지않도록 각별히 주의해야한다.

경계에 위치하는 코드는 깔끔히 분리한다. 기대치를 정의하는 테스트케이스도 작성해야한다 통제에 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리코드에 의존하는 편이 좋다. 또, 외부 패키지를 호출하는 코드를 가능한 최대한 감싸야 할것 같다.

단위테스트

대다수 단위 테스트란 자기 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과하였으나, 꼬치꼬치 따지며 코드가 제대로 작성되고 실행된 테스트를 볼때마다 기분이좋다. 한번에 하나씩 천천히..

1. TDD법칙 세가지

실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

위 세가지 규칙을 따르면 개발과 테스트가 30초 주기로 묶인다. 테스트 코드와 실제코드가 함께 나올 뿐더러 테스트코드가 실제코드보다 불과 몇초전에 나온다.

2. 깨끗한 테스트 케이스 코드 유지하기

지저분한 테스트 코드는 내놓으나 테스트를 안하나 , 오히려 더 못한다는 사실을 깨닳아야한다. 테스트 코드가 지저분할 수록 변경하기 더욱 어려워진다. 새 버전을 출시할때마다 팀이 테스트 케이스를 유지하고 보수하는 비용도 늘어난다. 점차 테스트 코드는 개발자 사이에서 가장 큰 불만으로 자리잡게된다. 하지만 테스트 슈트가 없으면 자신이 수정한 코드가 제대로 작동하는지 확인할 방법이 없다. 그래서 결함율이 높아지기 시작한다. 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다. 결국 득보다 해가 크다고 생각하여 코드가 정리되지 않고 , 망가지기 시작하며 테스트 슈트도 없고 얼기 설기 뒤섞인 코드에 좌절한 고객과 테스트에 쏟아부은 노력이 허사였다는 실망감만 남게된다.

결국 테스트 코드는 실제 코드못지 않게 중요하며, 테스트 코드 역시 실제 코드 못지않게 깨끗하게 짜야한다.

테스트 코드를 깨끗하게 유지하지않으면 결국 잃어버린다. 그리고 실제 코드를 유연하게 만드는 버팀목도 사라진다. 하지만 테스트 케이스가 있다면 그 공포는 사실상 사라지며, 테스트 커버리지가 높을수록 공포는 줄어든다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다.