토비의 스프링을 읽고 배우고 느낀점을 정리합니다.
1. 느낀점
좋은 습관의 중요성
지난 시간에 DI를 인터페이스를 통해 받아야 한다는 내용을 설명해 주시면서 그게 그렇게 어려운 일이 아니며 습관이 되게 하는 것이 중요하다는 이야기를 해주셔서 인상 깊었습니다. 2장을 읽으며 학습 테스트, 버그 테스트 같은 내용이 무척 유용한 실천법이란 생각이 들었는데 저도 몇 번 해 본적은 있지만 습관을 가지지 못했다는걸 깨닫게 되었습니다. 문득 가까이에 이런 좋은 실천법들을 몸소 보여주고 알려주는 동료가 있으면 좋다는 생각이 들었고, 앞으로 내가 습관으로 만들어서 주변에 좋은 본이되고 좋은 것을 전해주는 동료가 되어야 겠다고 생각했습니다.
포괄적인 테스트
테스트는 ‘포괄적’이어야 한다고 설명해 주신 부분이 좋았습니다. 책 설명에 테스트를 안 만드는 것보다 성의 없이(일부만) 테스트를 만드는 것이 더 문제이고 그것은 마치 멈춰 있는 시계가 하루에 두 번은 제대로 된 시간을 표시하는 것과 같다고 설명해 주셔서 실감나게 와닿았던 것 같습니다. 그 동안 테스트에 뭐가 중요하다라는 걸 다른 사람에게 설명할 때면 ‘모든’이라는 단어를 사용했는데 늘 걸림이 있었던 것 같습니다. 왜냐하면 많은 테스트 기법이 최소한의 테스트로 많은 케이스를 검증하려는 시도를 하는 부분도 있고 또 현실에서 모든 케이스를 테스트 할 수 없다는 반론이 설득력 있게 항상 존재하기 때문이었습니다. ‘모든’이라는 단어는 완벽한 전체라는 뉘앙스를 주는 반면에 ‘포괄적’이라는 단어는 적절한 범위안에 모두 들어오게 라는 뉘엉스를 주는 것 같아 훨씬 적절한 표현이라는 생각이 듭니다. 정리해보면 애플리케이션에 포함된 기능을 포괄적으로 테스트하고 여러가지 발생할 수 있는 예외 케이스까지 포괄적으로 테스트해야 한다고 설명하면 적절한 설명이란 생각이 들었습니다.
AOP에 대한 기대
AOP라는 기술은 애초에 DI를 적용하지 않았다면 불가능한 일이였다는 말이 인상적이었는데 아직 AOP를 제대로 맛보지 못했지만 다음에 나올 장들일 기대되었습니다.
2. 궁금한 점
커다란 기능을 TDD로 개발한다면
Q : 테스트 코드를 작성할 때 하나의 기능 내부 구현을 블랙박스로 보고 외부 인터페이스를 테스트 하려는 경향이 개인적으로 있습니다. 그런데 만약 TDD를 시도하는 경우인데 내부 구현에 참여하는 모듈이 다양하고 규모가 꽤 있는 경우 테스트 코드를 작성하고 테스트를 실행하기 까지 꽤 오랜 시간이 걸리는 경우가 있는 것 같습니다. 그래서 여러가지 문제를 만납니다. 여러 모듈이 있다보니 어디서 문제가 발생했는지 알기 어렵거나 테스트를 통해 즉시 확인 받으면서 코드를 작성하지 않으니 불안함이 이어지는 것도 같습니다. 이럴 때 블랙 박스 내부 구현 모듈 하나하나를 단위테스트 코드로 더 쪼개서 작성하는 편이신가요?
A : (스스로 답변을 생각해 보니) 질문을 정리하다 보니 이와 같은 문제가 있다면 더 작은 단위의 내부 모듈로 테스트를 분리할 수도 있겠습니다. 반면에 테스트 코드까지 작성하는 것이 과하다는 판단이 든다면 내부 모듈들은 간단히 디버거를 통해 한 줄씩 따라가며 확인해 보는 것도 괜찮은 방법 같습니다.
A : 단위 테스트의 범위를 어느 정도의 코드 크기로 잡을 것인지는 내가 어떤 코드를 확신할 수 없고 불안한지 생각해보고 유연하게 가져갈 수 있을 것 같습니다.
제한된 시간과 포괄성의 트레이드오프
Q : 현업에서 일하다보면 늘 시간이라는 제약을 마주합니다. 제한된 시간은 포괄적이라는 개념을 완벽하게 적용할 수 없게 하는 제약이 되는데요. 현업에서 제한된 시간 안에 포괄적인 테스트를 작성하는 지혜에 대해 나누어 보고 싶습니다. 예를 들면 어떤 종류의 테스트는 이럴 때 포기하기도 한다. 어떤 종류의 테스트는 꼭 사수한다와 같은 것들이요.
A : (스스로 답변을 생각해 보니) 저는 일정이 촉박한 경우는 모든 기능의 성공케이스만 일단 테스트 케이스를 작성하고 예외 케이스는 단위 테스트를 하면서 발견되는 예외 상황만 추가로 작성하는 등의 방법을 사용하는 것 같아요.
A : 단위 테스트의 범위를 어느 정도의 코드 크기로 잡을 것인지는 내가 어떤 코드를 확신할 수 없고 불안한지 생각해보고 유연하게 가져갈 수 있습니다.
3. 예제 코드 작성하며 배우기 (PR)
- #1 테스트 검증의 자동화
- #2 테스트의 효율적인 수행과 결과관리
- #3 테스트 결과의 일관성
- #4 포괄적인 테스트
- #5 Before 어노테이션을 활용한 중복 준비 작업 제거
- #6 스프링 테스트 적용
