핵심 내용 요약
- 단위테스트는 동작을 보장하고, 동작을 쉽게 이해하고, 코드 변경을 쉽게 할 수 있게 한다.
- 좋은 테스트가 무엇인지(FIRST), 무엇을 테스트할 것인지(Right-BICEP)를 고민하고 테스트를 작성해야 한다.
- 테스트와 설계, 리팩터링은 관련도가 높다. 리팩터링을 통해 코드를 깔끔하게 작성하면 테스트가 쉬워진다. 단위 테스트의 커버리지가 높으면 설계를 지속적으로 개선해 나가는 자신감을 키울 수 있다. 테스트 또한 리팩터링을 통해 이해를 높이고 유지 보수 비용을 최소화할 수 있다.
- 테스트도 SRP가 중요하다. 관심사를 분리하고 의존성을 분리하자. 목, 스텁 등의 방식을 고려하여 의존성을 끊을 수 있다. 필요한 경우에는 통합 테스트를 작성하되, 단순하고 집중적으로 만들자.
내 생각
요즘 테스트를 작성할 일이 별로 없었는데, 오랜만에 테스트 공부를 하니 우테코 레벨1으로 돌아간 것 같아서 재밌었다.
아예 처음 보는 내용은 거의 없었지만, 테스트에 대해 지금까지 다른 사람들과 이야기 해보았던 내용들이 거의 총집합으로 깔끔하게 들어있어서 읽기 좋았다. 특히 FIRST 속성, 경계값은 무엇을 테스트할 것인가 같은 내용들도 묵시적으로 알고 있었지만 이름을 붙여서 다시 알게되니 추가로 얻어가는 느낌이었다.
다만 아쉬운점은 2019년에 발행된 책이다보니 너무 과거의 JUnit 단언을 사용한다(AssertJ에 대해서는 나오지 않음). 하지만 JUnit 학습이 책의 주된 주제는 아니기 때문에 빠르게 넘기면서 보는 것을 추천한다.
추천 대상
- Java 기반의 책이다.
- 테스트를 한 번도 작성해보지 않은 사람은 추천하지 않는다. 테스트에 대해 잘 알 필요는 없지만, 정말 간단한 테스트 정도는 작성해보고 읽는게 좋다.
- JUnit을 공부하고 싶은 사람에겐 추천하지 않는다. 공식문서나 AI를 통해 공부하는게 더 좋다.
- 단위 테스트에 대해 일반적으로 통용되는 사실들, 기법들을 공부하고 싶은 사람에게 추천한다.
- 좋은 단위 테스트가 무엇인지, 외부 의존성이 있는 기능은 어떻게 테스트 해야하는지 궁금한 사람들에게 추천한다.
인상 깊은 or 기억하고 싶은 내용들
단위테스트를 작성해야 하는 몇 가지 상황과 이유
- 어떤 기능을 막 코딩했고 그것이 예상한 대로 작동하는지 알고 싶습니다.
- 시스템에서 작성한 변경 사항을 문서화하여 자신과 다른 사람들이 나중에 이해하도록 하고 싶습니다.
- 코드를 변경하고 그것으로 변경된 사항이 기존 동작을 깨뜨리지 않았는지 확인하고 싶습니다.
- 시스템의 현재 동작을 이해하고 싶습니다.
- 서드 파티 코드가 더 이상 기대한 대로 동작하지 않을 떄를 알고자 합니다.
5.3 F[I]RST: 고립시킨다
또 SRP는 테스트 메서드에서도 훌륭한 지침을 제공합니다. 테스트 메서드가 하나 이상의 이유로 깨진다면 테스트를 분할하는 것도 고려해 보세요.
5.6 FIRS[T]: 적시에 사용한다
마지막으로 옛날 코드에 대한 테스트는 시간 낭비가 될 수도 있습니다. 코드에 큰 결함이 없고 당장 변경할 예정이 없다면(즉, 코드를 변경하지만 현재에서 어떤 것도 깨지 않아야 할때) 여러분 노력은 거의 보상받지 못할 것입니다. 그 노력을 좀 더 말썽이 많고 역동적인 부분에 사용하세요.
9.4 단위 테스트의 유지 보수 비용
보통 돌아오는 가치가 훨씬 크기 때문에 깨진 테스트 코드를 고치는 비용을 받아들입니다. 앞서 결함이 거의 없는 코드를 갖는 이점과 다른 코드가 꺠질 것을 걱정하지 않으면서도 코드를 변경할 수 없는 이점, 그리고 코드가 정확히 어떻게 동작하는지 알 수 있는 이점(코드를 깊이 파고들어 무엇이 잘못되었는지 추측하느라 많은 시간을 소모하지 않고)을 이야기했습니다.
'독서' 카테고리의 다른 글
| [개발자 원칙]을 읽고 (0) | 2025.07.13 |
|---|