✅ 강의 수강

학습 요약

• Test Double -Mock과 Stub, @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks

   

• BDDMockito

• Mockist vs Classicist

   

• 테스트 작성 원칙

  • 테스트는 하나의 목적만 가지도록

  • 외부 요인에 영향을 받지 않는 고정된 Fixture

  • 필요한 데이터는 given절에, 간접 데이터는 @BeforeEach 등에서 처리

  • 테스트에 필요한 데이터는 가능한 제어 가능한 값으로 구성

  • 테스트 수행도 비용이므로 공통 환경을 모아 관리

     

• 학습 테스트 를 통해 익숙하지 않은 라이브러리나 기술을 익힐 수 있음!

학습 회고

4주간의 과정 동안 흐릿했던 지식들이 조금씩 뚜렷해지고, 그동안 무심코 사용하던 어노테이션이나 리팩토링과 테스트코드에 대해 왜 그런 식으로 쓰는지, 더 나은 방식은 무엇인지를 고민해볼 수 있었다. 처음에는 단순히 돌아가는 코드에 대한 확인 정도로만 생각했던 테스트를 이제는 책임을 분리하고 안정적인 코드를 만들기 위한 구조적 도구라고 인식하게 되었다. 4주동안 끝까지 놓지 않고 따라온 것 자체가 개인적으로는 작지 않은 성취였다. 리팩토링 / 테스트코드를 막연하게 두려워하기보다 하나씩 풀어나갈 수 있겠다는 마음이 생긴 것에 의미를 두고 싶다. 정말 좋은 기회였다고 느낀다!

✅ 미션

해결 과정

1번 미션에서는 Mockito와 Spring 환경에서 각각 사용되는 테스트 어노테이션들의 차이를 실제 사용 맥락을 중심으로 정리했다.

2번 미션에서는 각 객체 생성 및 동작을 어떤 위치에 배치할지 고민하며, 공통된 준비와 사용자와 게시물은 @BeforeEach에, 댓글을 직접적인 테스트 도메인으로 보고 given절에서 명시적으로 생성하는 구조로 정리했다.

미션 회고

어노테이션의 차이를 정리하면서 어떤 상황에서 어떤 걸 써야 좋을지 기준을 명확히 할 수 있었다. 테스트 흐름을 구성해보는 미션을 하면서 결국 핵심 도메인이 무엇인지, 어떤 객체가 테스트의 중심 대상인지 판단하고 구조를 잡는 게 중요하다는 걸 배웠다. 앞으로 테스트를 구성할 때도 도메인 흐름과 역할을 기준으로 구분하는 습관을 유지하고 싶다.