[클린코드] 8-9장. 경계, 단위 테스트

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다.

 

8장. 경계

개발을 하다 보면 모든 기능들을 직접 구현하지는 않는다. 때로는 무료로 공개된 라이브러리들을 사용하거나 돈을 내고 사용하는 경우도 있다. 

 

라이브러리를 사용하는 사용자들은 자신들의 요구에 딱 맞는 기능을 기대하고, 라이브러리를 만드는 개발자들은 최대한 범용적으로 사용할 수 있게 만들고 싶어 한다. 이러한 경우 때문에 문제가 생길 소지가 많다.

 

라이브러리를 사용하면 적은 시간에 더 많은 기능을 출시할 수 있어진다. 하지만 그 코드를 익히기 어렵다.

 

어떤 식으로든 나의 코드에 깔끔하게 통합해야한다.

 

무작정 라이브러리를 사용하기보단 간단한 테스트 케이스를 작성해서 라이브러리를 익히는 방법을 추천한다.

 

이를 학습 테스트라고 부른다.

 

9장. 단위 테스트

단위 테스트란 TDD다.

 

TDD 법칙 세 가지

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

세 가지 규칙을 따르게 되면 엄청난 테스트 코드가 만들어진다. 하지만 엄청난 양의 테스트 코드를 관리 문제를 일으킬 수 있다.

 

그래서 깨끗한 테스트 코드가 필요하다. 

 

가독성

 

테스트 코드는 가독성이 좋아야 한다. 명료, 단순해야 한다.

 

F.I.R.S.T

깨끗한 테스트는 다섯 가지 규칙을 따른다.

1. Fast : 빨라야 한다.
   테스트가 느리면 자주 테스트를 하지 못하기 때문이다. 그럼 결국 코드가 엉망이 될 것이다.
2. Independent : 서로 의존하면 안 된다. 
   서로 의존하게 되면 하나가 실패할 때 나머지도 연달아 실패하기 때문에 원인을 찾기 힘들어진다.
3. Repeatable : 어떤 환경에서도 반복 가능해야 한다.
   테스트가 되지 않는 환경이 있다면 테스트를 실패한 이유로 변명할 여지가 분명히 있다.
4. Self-Validating : bool값으로 결과를 내야 한다.
   테스트가 성공, 실패를 스스로 가늠해야지 로그 파일을 읽게 만들어서는 안 된다.
5. Timely : 적시에 작성해야 한다.
   테스트하려는 실제 코드를 구현하기 직전에 구현한다.
   실제 코드를 구현한 다음에 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할 수도 있다.

 

TDD가 무엇인지에 대해 궁금증이 생겼다. 

조만간 TDD에 대해서 정리해서 글을 쓰도록 해야겠다.

책을 읽으면 읽을수록 모르는 것이 더 쌓이고 공부해야 될 것이 점점 쌓이고 있다.

좋은데 싫다...