[워밍업 클럽 스터디 2기 - BE] (클린코드, 테스트코드) 4주차 발자국

인프런 워밍업 클럽 스터디 2기 - 백엔드 클린코드, 테스트 코드(Java, Spring Boot)

Practical Testing: 실용적인 테스트 가이드

해당 강의를 학습하며 정리하는 내용입니다.

드디어 마지막 주차 발자국을 작성하는 시간이다.

이번주에는 Mock관련 내용과, 테스트를 작성하기 위한 팁, Spring REST Docs에 대해 배우는 주차였다.

Mock을 마주하는 자세

Test Doble

외부 API같이 내가 직접 테스트 하기 어려운 것들을 가짜로 대체해서 테스트 하는 테스트 방법론

• Dummy

  • 아무것도 하지 않는 깡통 객체

• Fake

  • 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체 (ex. FakeRepository)

• Stub

  • 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체. 그 외에는 응답하지 않는다.

• Spy

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

  • 일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있다.

• Mock

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

Stub : 상태 검증 (State Verification)

Mock : 행위 검증 (Behavior Verification)

Classicist VS. Mockist라는 말을 처음 들어봤는데, 실제 객체로 통합 테스트를 해가면서 필요할 때만 Mocking해서 사용하자는 Classicist파와, 각각 따로따로 다 목킹해서 순수 코드만 빠르게 테스트 하자 라는 Mockist파의 싸움 같은 거다.

나도 이에 대해 생각을 해봤는데, 나는 Mockist에 좀 더 가까운 거 같다. Mockist가 좀 더 뭔가 작은 블럭을 쌓아가서 전체를 만드는 느낌이 든다.

하지만 분명히 Mockist여도 통합테스트 해야하고 Classicist여도 목킹을 통한 단위테스트는 해야한다.

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks

이거에 관하여 미션이 나갔다.

@Spy는 진짜 처음봐서 좋은 기능 배웠다고 생각한다.

day-18 미션

그리고 테스트 분류 미션에 관해서도 깜짝 라이브를 통해 우빈님의 의도를 들었었는데, setUp, given, when, then에 두어야 할 것에 대한 생각을 정리할 수 있게 된것 같다.

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

여기서는 다양한 테스트 꿀팁들을 배웠다.

키워드

• 한 문단에 한 주제

  • 글쓰기와 같다. 한 테스트에 한 주제

• 완벽하게 제어하기

  • LocalDateTime.now() 같이 달라질 수 있는 값들은 사용하는 것을 지양하자.

• 테스트 환경의 독립성을 보장하자

  • 지금 하고 있는 테스트의 주제를 잘 생각하고, when, then절이 아닌 다른 곳에서 테스트가 깨지지 않도록 하자.

• 테스트 간 독립성을 보장하자

  • A → B, B → A 순서가 바뀐다고 테스트가 바뀌면 안된다.

• 한 눈에 들어오는 Test Fixture 구성하기

  • given절에 생성한 모든 객체들

• Test Fixture 클렌징

  • deleteAllInBatch() vs deleteAll() vs @Tranjactional

• @ParameterizedTest

  • if 분기문, 반복문 등 → 생각의 사고를 추가 해야 하는, 즉 읽기 힘든 테스트가 된다.

  • 값이나 환경만 바꿔가면서 테스트를 여러번 반복 하고 싶을 때 사용하면 좋다.

• @DynamicTest

  • 일련의 시나리오를 테스트 하고 싶을 때가 있다. 그럴때 사용하면 좋은게 @DynamicTest이다.

• 테스트 수행도 비용이다. 환경 통합하기

  • @SpringBootTest를 사용할 때 조금이라도 프로파일이라던지 이런 설정이 달라지면 다 다른 설정으로 스프링이 올라간다.

• Q. private 메서드의 테스트는 어떻게 하나요?

  • 결론은 안하는게 맞다.

• Q. 테스트에서만 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없다면?

  • 만들어도 된다. 하지만 보수적으로 접근하기!

하나 같이 막힐때 큰 도움이 될 거같은 조언이다.

Appendix

학습 테스트

• 잘 모르는 기능, 라이브러리, 프레임워크를 학습하기 위해 작성하는 테스트

• 여러 테스트 케이스를 스스로 정의하고 검증하는 과정을 통해 보다 구체적인 동작과 기능을 학습할 수 있다.

• 관련된 문서만 읽는 것보다 훨씬 재미있게 학습할 수 있다.
  

Spring REST Docs

• 테스트 코드를 통한 API 문서 자동화 도구

• API 명세를 문서로 만들고 외부에 제공함으로써 협업을 원활하게 한다.

• 기본적으로 AsciiDoc을 사용하여 문서를 작성한다.

REST Docs

• 장점

  • 테스트를 통과해야 문서가 만들어진다. (신뢰도가 높다.)

  • 프로덕션 코드에 비침투적이다.

• 단점

  • 코드 양이 많다.

  • 설정이 어렵다.

Swagger

• 장점

  • 적용이 쉽다.

  • 문서에서 바로 API 호출을 수행해볼 수 있다.

• 단점

  • 프로덕션 코드에 침투적이다.

  • 테스트와 무관하기 때문에 신뢰도가 떨어질 수 있다.

Spring REST Docs는 문서화를 도와주는 도구인데 설정이 좀 많이 어려운 듯 하다. 추가적인 공부가 많이 필요한 것 같다.

한번은 배워보고 싶은 도구였어서 좋은 계기였다.

전체 회고

드디어 4주의 학습 스터디가 끝났다. 개인적으로 퇴사를 앞두고 있는데, 이제서야 이런 좋은 학습 기회가 있다는 것을 알아서 좀 아깝지만 늦었다고 생각할 때가 가장 빠르니까 좋게 생각한다.

2년동안 개발을 하면서 테스트나 클린 코드를 생각안해본건 아닌데, 솔직히 현재 업무에서 살짝살짝 내가 혼자 학습해서 조금씩 적용해본 정도지, 진지하게 공부하고 사용해 본적은 없었다.

이번 강의가 클린코드, 테스트 코드 두 강의나 돼서 좀 듣기 빡세긴 한데, 진짜 도움이 많이 되는 것 같았다.

클린 코드는 내가 코드를 보는 생각이 좀 더 열린 계기가 된 것 같고, 테스트 코드는 평소에 배우고 싶다는 갈망이 많이 채워졌다.

앞으로 두 내용에 대해 좀 더 학습해 나아가면서 지금 배웠던 것들이 기초가 될 것이라고 생각한다.

다음에도 이런 좋은 주제가 있으면 언제든지 참가하고 싶다.