14. 테스트와 가독성

이 글은 읽기 좋은 코드가 좋은 코드다(더스틴 보즈웰, 트레버 파우커 지음 / 임백준 옮김 / 한빛미디어) 를 읽고 내용을 정리한 글입니다.

<<간결하고 효과적인 테스트 코드!>>

 

1. 읽거나 유지보수하기 쉽게 테스트를 만들어라

-> 테스트 코드: 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서

-> 테스트 코드가 읽기 쉬우면, 사용자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다.

-> 다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있게 테스트 코드는 읽기 쉬워야 한다.

 

2. 테스트를 읽기 쉽게 만들기

-> 덜 중요한 세부 사항은 사용자가 볼 필요 없게 숨겨서 더 중요한 내용이 눈에 잘 띄게 해야 한다.

-> 초기화에 필요한 부분은 헬퍼 함수를 사용해 감추고, 테스트 자체에 더 집중될 수 있도록 하라!

-> 최소한의 테스트 구문 만들기: 테스트 코드를 최대한 짧고, 읽기 쉽게 만들어라!

-> 목적에 맞는 '미니-랭귀지' 구현하기: 문자열에 일정한 문법적 규칙을 도입해 자신만의 최적화된 미니-랭귀지를 만들어 사용하라!

 

3. 읽기 편한 메시지 만들기

-> 에러 메세지를 읽기 쉽게 만들어라

-> 에러 메세지는 최대한 유용해야 한다! 

-> 목적에 맞는 assert를 스스로 구현하라!

 

4. 좋은 테스트 입력값의 선택

-> 가능하면 가장 가단한 입력으로 코드를 완전히 검사할 수 있어야 한다!

-> 필요한 작업을 수행하는 범위에서 가장 명확하고 간단한 테스트 값을 선택하라!

-> 하나의 '완벽한' 입력을 사용하는 것보다는 작은 테스트를 여러 개 사용하는 방식이 더 쉽고 효과적이다.

 

5. 테스트 함수에 이름 붙이기

-> Test1() 과 같이 전혀 의미가 없는 이름을 사용하지 마라.

-> 테스트를 상세하게 묘사할 수 있는 이름을 사용하라.

-> 'Test_' 접두사를 사용하여 테스트되는 클래스, 함수, 상황이나 버그 등 필요한 정보를 하나로 붙여 사용하는 것도 좋다!

-> 테스트 함수는 실제 코드베이스에서 호출되는 함수가 아니므로, 이름을 하나의 설명문으로써 길게 가져가도 상관없다!

-> 테스트 코드 내부 헬퍼 함수의 경우, 테스트와 상관없는 '순수한' 헬퍼인지 아닌지를 확인 가능한 이름을 사용하는 것이 좋다!

 

6. 테스트에 친숙한 개발

-> TDD: 실제 코드를 작성하기 전에 우선 테스트 코드부터 작성하는 기법

-> 테스트 하기 어려운 코드의 특징: 전역 변수 사용, 코드가 많은 외부 컴포넌트 사용, 코드가 비결정적인 행동을 가진다.

 

7. 지나친 테스트

-> 테스트를 가능하게 하려고 실제 코드의 가독성을 희생시키지는 마라.

-> 100% 코드 테스트는 존재하지 않으며, 필요하지도 않다.

-> 프로젝트에 따라 테스트 코드를 작성하는 것이 중요하지 않을 수도 있다.

-> 테스트 코드 작성이 프로젝트의 진행에 크게 영향을 주어서는 안된다.