1. 들어가며

시간이 굉장히 빠르네요. 얼마전에 OT를 듣고 진도표가 굉장히 빡세다고 느껴졌었는데 워밍업 클럽이 마무리가 되었습니다. 👏👏

저는 개인적으로 어느정도 강제성이 생겨서 더 좋았던 것 같습니다. 하지만 직장인이 하기에는 시간적으로 부담이 되는게 사실입니다...

어찌어찌 완강을 했고, 실제로 실무에서 조금씩 개념들을 적용해보는 시간들이 가지려고 합니다.

그리고 아직 강의가 100% 저만의 키워드로 정리가 되지는 않았기 때문에 몇 번 회독을 해야할 것 같긴 합니다.

2. 학습했던 내용 나만의 키워드로 작성하기

섹션 7. Mock을 마주하는 자세

• Test Double, Stubbing

  • dummy

    • 실제 객체를 모방하기만 한 아무 동작도 안하고 아무 행위도 안하는 깡통 객체입니다.

    • 그래서 활용할 일은 거의 없습니다.

  • fake

    • 실제 객체의 행위와 동일한 기능은 수행하나, 좀 더 단순한 형태로 수행을 합니다.

    • 그래서 프로덕션에서 쓰기에는 부족한 객체입니다.

  • stub

    • 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체입니다.

  • spy

    • Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체입니다.

  • mock

    • 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체입니다.

• @Mock

  • Mockito에서 제공하는 어노테이션으로, 테스트에서 사용할 가짜 객체(mock)를 생성합니다.

  • 주로 단위 테스트에서 의존성을 대체하기 위해 사용됩니다.

• @MockBean

  • Spring Boot의 테스트에서 사용되는 어노테이션으로, Spring ApplicationContext에 mock 객체를 등록합니다.

  • 주로 통합 테스트에서 사용되며, Spring의 의존성 주입을 통해 mock 객체를 주입받을 수 있습니다.

  • @SpringBootTest와 함께 사용됩니다.

• @Spy

  • 한 객체에서 일부는 실제 객체의 기능을 쓰고 싶고 일부만 stubbing 을 하고 싶을 때 @Spy 를 사용합니다.

• @SpyBean

  • @MockBean과 유사하지만, 실제 객체의 메서드를 호출할 수 있는 spy 객체를 생성합니다.

• @InjectMocks

  • 테스트 대상 클래스의 생성자, 필드, 또는 setter 메서드를 통해 mock 객체를 자동으로 주입합니다.

  • 주로 단위 테스트에서 사용됩니다.

• BDDMockito

  • given-when-then 스타일로 작성을 도와주는 Mockito 를 감싼 것

• Classicist VS. Mockist

  • Classicist: 진짜 객체로 최대한 테스트를 해야한다

  • Mockist: 각각 테스트를 잘 했으니 통합 테스트를 할 때는 다 Mocking 처리해서 기능 보장된 것들은 Mocking으로 빠르게 쳐내고 테스트를 빠른 시간안에 한다.

  • 개인적으로 둘 중 뭐가 중요하다보다는 테스트 코드를 잘 작성하는 게 중요한 것 같다.

섹션 8. 더 나은 테스트를 작성하기 위한 구체적 조언

• 테스트 하나 당 목적은 하나!

  • 한 가지 테스트에서는 한 가지 목적의 검증만 수행하는게 좋음.

• 완벽한 제어

  • 현재 시간, 랜덤 값, 외부 시스템과 연동하는 경우 등에 대해서 제어할 수 있게 설정하는게 중요

• 테스트 환경의 독립성, 테스트 간 독립성

  • 팩토리 메서드 보다는 순수한 빌더나 순수한 생성자로만 테스트 given 절을 구성하는게 더 좋음

  • 공유 자원에 대한 것들은 사용하지 않아야 함.

• Test Fixture

  • @BeforeAll 과 @BeforeEach 에 Test Fixture 구성하지 않기

  • data.sql 에 Test Fixture 구성하지 않기

  • Test Fixture 의 메서드는 필요한 파라미터로만 구성하기

  • 픽스처를 만들기 위한 빌더들을 한 곳에 모으는 것을 지양하기

• deleteAll(), deleteAllInBatch()

  • 테스트도 결국 비용

  • 관계 정도만 생각을 하면 충분히 벌크 연산인 deleteAllInBatch() 로 한번에 깔끔하게 날릴 수 있기 때문에 deleteAllInBatch() 사용이 낫다.

• @ParameterizedTest, @DynamicTest

  • @ParameterizedTest: 딱 하나의 테스트 케이스인데 값을 여러 개로 바꿔보면서 테스트를 하고 싶은 경우

  • @DynamicTest: 하나의 환경을 설정해놓고 사용자 시나리오 테스트

• 수행 환경 통합하기

  • 빠른 시간 안에 효과적으로 테스트를 수행할 수 있을지 고민해야 함

• private method test

  • 할 필요가 없다.

• 테스트에서만 필요한 코드

  • 최대한 지양하는것이 좋다.

3. 학습 회고

저의 목표는 단순히 개념을 익히는 것이 아니라, "실무에서 직접 사용해보는 것"입니다.

물론 키워드만 알고 있어도 도움이 되겠지만, 직접 적용해 본 경험이 있는 것과 없는 것의 차이는 매우 크다고 생각합니다.

이번 과정에서 정말 많은 개념과 기술을 배웠고, 이제는 이를 실제 코드로 구현하고, 직접 사용해보면서 제 것으로 만들어야겠죠.

배움에서 그치지 않고, 실무에서도 활용할 수 있는 개발자로 성장해 나가겠습니다! 🚀🔥

정말 도움이 많이 되는 강의 2개였습니다.

워밍업 클럽 같은 더 좋은 기회가 있다면 또 참여하고 싶네요.

4. 미션 회고

미션 Day 16, 18

크게 어려운 미션은 없었습니다. 간단한 키워드 정리만 있었죠.
미션이 쉬웠던 이유는 아마 테스트 코드 강의에서 과부하가 걸릴거라고 생각했던 것 같습니다. ㅋㅋㅋ

처음 강의를 들을 때 기존에 작성했던 테스트 코드는 사실 테스트 코드라고 부르기 어려웠던 것 같습니다.
우빈님이 소개해준 테스트 방식이 정답은 아니지만 굉장히 많은 도움이 됐던 것은 사실이고 현재도 소개받은 테스트 방식으로 작성하고 있습니다.

조금씩 적절하게 응용할 수 있는 좋은 자산이 되었습니다!