코드숨 스프링 편 3주차 회고: 테스트

Jake Seo·2022년 4월 13일
0

이번 주에 한 것

간단하게 말하면, 테스트를 작성했다.

  • 유닛 테스트 작성
  • 계층형 테스트 작성
    • 준비, 시작, 단언 (AAA, arrange-act-assert) 규약을 약간 변형했다.
    • Given, When, Then 에서 Describe, Context, It 이 된다.
  • Controller 에 대한 Mock 테스트 작성
    • @WebMvcTest 를 이용한 웹 레이어 테스트
    • @AutoConfigureMockMvc 를 이용한 통합 테스트
  • Test Double 에 대한 학습
  • Mockito 활용법에 대한 학습

배운 것 1: 테스트 코드조차 코드의 퀄리티가 중요하다.

  • 의도를 명확히 드러내기 위해서 JUnit5 가 기본적으로 제공하는 단정문(Assertion)이 아닌 AssertJ 라이브러리를 따로 설치해서 이용했다.
  • 고정적으로 사용되는 데이터를 Fixture 라는 형태로 만들어두어 재사용했다.
  • 그 외에도, 비슷한 메서드가 매 테스트마다 쓰이는 경우엔 상속 등을 이용할 수 있었고 일반 코드 퀄리티를 지키듯 테스트 코드도 코드 퀄리티를 지켜나갔다.

배운 것 2: 테스트 코드는 항상 꼼꼼하게 작성해야 한다.

  • 특히 정상 작동하는 것 외에 정상작동하지 않을만한 것에 집중해보자.
    • 경계값, 예상치 못한 입력값, 쉽게 생각할 수 있는 틀린 값 등을 테스트해보자.

배운 것 3: 테스트 대상 코드를 격리해보자.

  • 스프링의 웹 아키텍처에서 가장 널리 쓰이는 레이어로는 Controller, Service, Repository 가 있다. 이를 레이어 별로 나눠서 잘 테스트할 수 있다면, 해당 레이어는 다른 레이어의 영역에 침범하지 않는 것으로 간주할 수 있다.
  • Mock 을 적극 활용하면 테스트 대상 코드를 격리할 수 있다.
    • 단, Mock 을 이용한 격리는 상호작용하는 다른 객체가 올바르게 값을 준다는 가정 하에 이뤄지는 테스트이니 꼭 통합 테스트로 다시한번 검증해보자.

배운 것 4: Mock 은 왜 사용하는가?

  • 객체간의 관계를 알 수 있다.
  • "Mocking 이 너무 어렵다는 것은 => 결합도가 높다. => 설계 개선이 필요하다."

과제 풀이 영상 리뷰

과제를 하며 배운 것 1: Mock 을 적극 활용하여 코드 격리를 한다.

  • Mockito 에는 spy(), given(), verify(), eq(), any() 등 어떤 객체든 흉내낼 수 있는 다양한 메서드를 제공한다.
  • 풀이 영상에서는 이를 적극 활용하여 각각의 레이어를 나눠 테스트했다.
    1) Service 레이어에서는 Mocking 없이 꼼꼼한 유닛 테스트로 동작을 보장했다.
    2) Controller 레이어에서는 Controller 에 정상적인 Service 가 주입되어 있다고 가정하에 Controller 객체가 올바르게 동작하는지 테스트했다.
    3) Web 레이어에서는 mockMvc를 이용해서 실제로 HTTP 요청을 하는 것처럼 테스트를 해보았다.

코드 리뷰에서 지적받은 것

ParameterizedTest 고려의 필요성

ParameterizedTest 의 경우, 아직 한번도 사용해본 적이 없는데, 특정한 파라미터가 오면 이뤄지는 동작이라는 것을 더 강조하고 싶을 때 사용해보면 괜찮을 것 같다.

위에서는 task.setTitle() 에 오는 파라미터에 따라 달라지는 동작을 표현했으면 더 좋았을 것 같다.

테스트에서 사용된 애매한 단어 '잘못된'

잘못된 이라는 단어는 구체적이지 않다. 존재하지 않는 ID, 형식에 맞지 않는 ID 등으로 테스트의 목적을 작성할 때는 더욱 구체적으로 작성해보자.

너무 긴 변수명은 쓸데 없는 주의를 끈다.

위에서 taskArgumentWithTitle 은 사실 딱히 길게 쓸 이유는 없는 변수명이다. 너무 길게 지어서 쓸데 없는 주의를 끌지 말자.

내가 느낀 것

  • 테스트를 이용해 코드를 빠르게 작성하면, 쉽게 리팩토링할 수 있다는 장점이 있다.
  • 테스트 코드에서도 코드의 퀄리티를 지키려 노력해야 한다.
  • 테스트 영역을 격리하여 관심사의 분리를 확실히 하고, 어떤 영역에서 문제가 발생했는지 더 확실히 알아보자.

여전히 남은 의문사항

  • 모든 메서드에 대해 테스트를 만드는 것이 바람직한가?
    • 가끔은 시간낭비가 아닐까? 일단은 학습 단계이니 작성해보자.
  • @Service 를 테스트할 때 통합 테스트와 Mock 테스트 어떤 것을 우선시 해야하는가?
    • 분리 테스트: @WebMvcTest 를 사용하고 Service 에 대해 @MockBean 을 사용하는 것
    • 통합 테스트: @SpringBootTest@AutoConfigureMockMvc 를 사용하는 것
profile
풀스택 웹개발자로 일하고 있는 Jake Seo입니다. 주로 Jake Seo라는 닉네임을 많이 씁니다. 프론트엔드: Javascript, React 백엔드: Spring Framework에 관심이 있습니다.

0개의 댓글