포스트

Spring: 개발자의 자신감, 테스트

Spring: 개발자의 자신감, 테스트

“테스트란 내가 짠 코드가 내 뒤통수를 치지 않게 막아주는 가장 저렴하고 확실한 보험이다.”

토비의 스프링 2장은 단순히 테스트 프레임워크 사용법을 넘어 개발자가 자신의 코드를 확신하고 꾸준히 개선하기 위한 ‘테스트 정신’을 다룹니다.


1. 테스트의 유용성

대부분의 개발자가 테스트를 귀찮아하는 이유는 “눈앞의 기능을 만드는 데 시간이 부족해서”라고 말합니다. 하지만 테스트는 시간을 뺏는 것이 아니라 결국 시간을 벌어다 주는 도구입니다.

  • 코드에 대한 확신: 수정한 코드가 기존 기능을 망가뜨리지 않았다는 것을 단 몇 초 만에 확인할 수 있습니다.
  • 두려움 없는 리팩터링: “이거 고쳤다가 다른 데 터지면 어떡하지?”라는 공포에서 해방됩니다. 테스트가 있다면 언제든 더 나은 구조로 코드를 개선할 수 있습니다.

2. 작은 단위의 테스트 (Unit Test)

테스트는 작을수록, 빠를수록, 독립적일수록 가치가 높습니다.

  • 관심사의 분리: DB 연결, 서버 기동 등 복잡한 환경을 다 끌어오지 않고 내가 짠 특정 로직(메서드)만 떼어내서 확인하는 것이 핵심입니다.
  • 빠른 피드백: 테스트 한 번 돌리는 데 시간이 오래 걸린다면 아무도 안 돌리게 됩니다. 작은 단위 테스트는 0.1초 만에 끝나야 하며 그래야 개발 과정에서 수시로 돌려볼 수 있습니다.

img


3. 자동 수행과 검증의 자동화

과거에는 콘솔에 System.out.println()을 찍고 눈으로 직접 확인했습니다. 하지만 이것은 수동적이며 실수가 잦은 ‘반쪽짜리’ 테스트입니다.

  • 자동 수행: 버튼 클릭 한 번, 혹은 빌드 시점에 수백 개의 테스트가 순식간에 돌아가야 합니다.
  • 검증의 자동화: “결과값이 ‘A’가 맞나?”라고 사람이 판단하는 게 아니라 코드가 직접 기대값과 실제값을 비교해야 합니다. 개발자는 Success(Green) / Fail(Red) 결과만 확인하면 됩니다.

4. 지속적인 개선과 점진적인 개발

테스트는 기능을 다 만든 뒤에 하는 ‘숙제’가 아닙니다.

  • 점진적인 개발: 작은 기능을 만들고 테스트하고 또 다음 작은 기능을 붙여나가는 방식은 설계의 결함을 초기에 발견하게 해줍니다.
  • 회귀 테스트 (Regression Test): 새로운 기능을 추가했을 때 과거의 기능들이 여전히 잘 작동하는지 보장해주어 프로젝트가 지속적으로 개선될 수 있는 발판이 됩니다.

5. JUnit

자바 개발자에게 JUnit은 테스트의 표준이자 가장 강력한 무기입니다.

  • 효율적인 수행: @Test, @BeforeEach 등의 어노테이션으로 테스트 환경(Fixture)을 손쉽게 설정하고 반복 실행할 수 있습니다.
  • 결과 관리: IDE 및 빌드 도구와 통합되어 실패한 지점과 원인을 명확히 시각화해주므로 디버깅 시간을 크게 줄여줍니다.

오늘의 회고: 테스트는 설계의 거울이다

테스트하기 좋은 코드가 좋은 코드다

토비의 스프링을 읽으며 가장 크게 깨달은 점은 테스트를 짜기 어렵다면 내 코드의 설계에 문제가 있을 확률이 높다는 것입니다. 객체 간의 결합도가 너무 높거나 책임이 분리되지 않았을 때 테스트 코드는 복잡해집니다. 즉 테스트는 내 코드의 설계 품질을 측정하는 가장 정직한 척도가 됩니다.

다짐

이제는 “기능 구현 완료”의 정의를 “코드를 다 작성했을 때”가 아니라 “테스트 코드까지 모두 통과했을 때”로 바꾸겠습니다. JUnit의 초록색 바(Green Bar)를 보는 즐거움을 습관으로 만들고 꾸준히 개선할 수 있는 단단한 코드를 짜는 개발자가 되겠습니다.


References

  • 토비의 스프링 3.1 Vol. 1
  • JUnit 5 User Guide (Official Documentation)
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.