자바와 JUnit을 활용한 단위테스트_11

11장. 테스트 리팩토링.

테스트 코드는 상당한 투자를 의미한다. 테스트는 결함을 최소화하고 리팩토링으로 프로덕션 시스템을 깔끔하게 유지시켜 주지만, 이것은 지속적인 비용을 의미하기도 한다. 이 장에서는 비용 증가로 이어지는 테스트 문제들을 해결할 것이다. 프로덕션 시스템을 리팩토링 하는 것처럼 테스트를 리팩토링하고 이해도를 최대화하며 유지 보수 비용을 최소화할 것이다.

---

불필요한 테스트 코드

테스트 코드가 예외를 기대하지 않는다면 단지 예외가 날아가게 두면 된다.
예외가 발생한 테스트는 오류로 표시되고 출력 창에 스택 트레이스가 보인다. 명시적인 try/catch 블록은 부가 가치가 업다.
try/catch 블록을 제거하고 메서드의 원형을 IOException을 던지도록 변경하자.

추상화 누락

추상화로 필수적인 개념을 최대화하고 불필요한 세부 사항은 감춘다.
단일 개념을 구현하는 2줄 혹은 3줄이 넘는 코드를 발견했다면 테스트에 그것을 깔끔한 문장 1문장으로 추출할 수 있는지 고민해보자.
단언을 바꾸면 크기 비교를 이해하는 불필요한 정신적 노력을 줄일 수 있다.

부적절한 정보

잘 추상화된 테스트는 코드를 이해하는 데 중요한 것을 부각시켜 주고 그렇지 않은 것은 보이지 않게 해 준다.
테스트에 사용된 데이터는 스토리를 말하는 데 도움을 주어야 한다.
때때로 테스트에는 부적절하지만 당장 컴파일되어야 하기 때문에 데이터를 넣기도 한다.

프로그래밍에서 상수로 선언하지 않은 숫자 리터럴을 '매직 넘버'라고도 하며 코드에는 되도록 사용하면 안 된다.
이런 매직 넘버보다는 의미 있는 이름을 가진 상수를 도입하여 즉시 파악할 수 있도록 하는 것이다.

다수의 단언

테스트마다 단언 한 개로 가는 방향은 좋은 생각이다.
때때로 단일 테스트에 사후 조건에 대한 단언이 필요하기는 하지만,
그보다 더 자주 여러 개의 단언이 있다는 것은 테스트 케이스를 두 개 포함하고 있다는 증거이다.
테스트를 두 개로 분할하면 각각을 좀 더 간결하게 테스트 맥락에 맞도록 기대하는 행동을 기술할 수 있다.

테스트와 무관한 세부 사항들

테스트를 실행할 때는 로그를 끄지만 그렇게 하는 코드는 테스트의 정수를 이해하는 데 방해물이 될 수 있다.
이런 군더더기들(세부 내용들)을 @Before와 @After 메서드로 이동시키자.
이때 테스트를 이해하는 데 필요한 유용한 정보는 제거하지 않았는지 한번 더 확인하면 좋다.

잘못된 조직

테스트에서 어느 부분들이 준비(Arrange), 실행(Act), 단언(Assert) 부분인지 아는 것은 테스트를 빠르게 인지할 수 있게 한다.
AAA를 통해 의도를 분명히 하고 해당 부분에 빈 줄을 삽입하여 가독성을 한번 더 높여주자.