[ 박우빈 Practical Testing #3 ] 더 나은 테스트를 작성하기 위한 Tip (1)

① 한 문단에 한 주제
② 완벽하게 제어하기
③ 테스트 환경의 독립성을 보장하자.
④ 테스트 간 독립성을 보장하자.
⑤ 한 눈에 들어오는 Test Fixture 구성하기
⑥ Test Fixture 클렌징
⑦ 테스트 수행도 비용이다. 환경 통합하기
⑧ private 메서드의 테스트
⑨ 테스트에서 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없는 경우

① 한 문단에 한 주제
: 한 문단에는 하나의 주제만 있어야 한다.

• 하나의 테스트가 한 문단이라고 생각해보자. 그러면 하나의 테스트는 하나의 주제만을 가지는 게 좋다.
• 즉, 하나의 테스트는 한가지 목적에 대한 검증만 수행해야 한다.
  • 이 말은 @DisplayName 을 한 문장으로 구성할 수 있는가 라는 말로 치환해서 이야기할 수 있다.
• 참고) 하나의 테스트가 한가지 목적에 대한 검증만 수행하도록 하기 위해서는, 테스트 코드에는 분기문이나 반복문 같은 추가적인 생각이나 판단을 요구하는 논리구조의 사용을 최대한 지양하는게 좋다.
  
  • 이러한 로직들이 들어간다는 것은 애초에 테스트 케이스가 2개 이상이라는 것을 의미한다.
    • 그런 경우 별도의 테스트 케이스로 풀어내는게 좋다.
    • 만약 케이스 확장이 필요하다면, @ParameterizedTest 등을 활용할 수 있다.
  • 분기문이나 반복문 같은 논리구조들이 들어간 테스트는, 사실 한 문단에서 두 가지 이상의 내용을 포함하고 있다는 것을 의미한다.
    • 분기문을 사용한다는 것은, 두 가지 경우에 따라 구분해서 나눠보겠다는 것을 의미한다.
    • 반복문의 경우는, 테스트 코드를 읽는 사람이 지금 이 코드는 뭘 테스트 하려고 하는것인지 분석을 요구하도록 한다.
      • depth 를 파고들어가면서 파악해야 한다.
  • 이런 논리구조는 테스트 코드가 지향하는, 무엇을 테스트 하고자 하는가에 대한 것을 명확하게 파악하는데 방해가 될 수 있다.
• 정리) 테스트 작성시 분기분이나 반복문 등의 논리구조가 들어가지 않도록 하고, 하나의 테스트는 한 가지 목적의 검증만 수행하도록 하자.

✔️ 참고 - @ParameterizedTest ( 다중케이스가 필요한 경우 )

• 하나의 테스트 케이스에서 값을 여러개로 바꿔보면서 테스트하고 싶을 때 @ParameterizedTest 라는 JUnit 애노테이션을 사용할 수 있다.
  
  • 위 테스트는 모든 ProductType 에 대해서 각각 재고 대상에 해당하는 상품 유형인지 검증하는 테스트이다.
  • 이렇게 코드를 작성하게 되면, ProductType 유형이 많아질수록 점점 어떤 타입이 어떤 결과인지 등을 보기가 어려워 진다. 이런 경우 @ParameterizedTest 를 사용할 수 있다.
    
    • @Test 대신 @ParameterizedTest 를 선언한다.
    • Source 를 줄 수 있다. 여기서는 @CsvSource 를 사용했다.
      • 참고) Csv: 콤마 구분자로 이루어진 형식
    • @CsvSource 내부에 정의한 값들은, 테스트 메서드의 파라미터로 구분되어 들어오게 된다.
    • 참고) Source 의 경우 다양하게 적용할 수 있다. ( @MethodSource, @ValueSource , ... )

강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 박우빈 강사님께 있습니다.