[7주차-1] 테스트 코드와 유지보수 (1/2) - 2jigoo

[2jigoo]

Chapter 10. 테스트 코드와 유지보수 (1/2)

스터디 일시 2023.09.14

목표

• [x] ~ p. 227 까지

[2jigoo]

Chapter 10. 테스트 코드와 유지보수

테스트 코드와 유지보수

• 빠른 서비스 출시를 위해 CI/CD 도입이 증가했고, 기능의 동작을 보장하기 위해 자동화 테스트가 CI/CD의 필수 요건 중 하나가 됐다 .
• 테스트 코드는 코드를 변경 했을 때 기존 기능이 올바르게 동작하는지 확인하는 회귀 테스트(regression test)를 자동화하는 수단으로 사용된다.
• 깨진 테스트를 방치하면 회귀 테스트가 검증하는 범위가 줄어들게 되고, 버그가 발생했을 때 이를 놓칠 가능성이 커지는 것을 의미한다.
• 테스트 코드를 유지보수하기 좋아야 지속적으로 테스트를 작성하게 되고 소프트웨어의 품질이 떨어지는 것을 막을 수 있다.

변수나 필드를 사용해서 기댓값 표현하지 않기

@Test
void dateFormat() {
    LocalDate date = LocalDate.of(1945, 8, 15);
    String dateText = formatDate(date);

    // X
    // - 문자열 연결이 있어 복잡
    // - date.getMonth()로 잘못 사용하면?
    assertEquals(date.getYear() + "년 " + 
            date.getMonthValue() + "월 " +
            date.getDayOfMonth() + "일", dateText);

    // O
    // 해당 테스트가 실패하면, formatDate 메서드만 확인하면 된다.
    assertEquals("1945년 8월 15일", dateText);
}

// 필드 또는 변수 사용 X
// 테스트가 실패했을 때, 사용했던 필드나 변수가 무엇인지 확인해야하는 번거로움
// 값을 바로 사용하면 직관적으로 확인할 수 있음

// private List<Integer> answers = Arrays.asList(1, 2, 3, 4);
// private Long respondentId = 100L;

@Test
public void saveAnswerSuccessfully() {
    // 답변할 설문이 존재
    Survey survey = SurveyFactory.createApporvedSurvely(1L);
    surveyRepository.save(survey);

    SurveyAnswerRequest surveyAnswer = SurveyAnswerRequest.builder()
            .surveyId(1L)
            .respondentI2(100L)
            .answers(Arrays.asList(1, 2, 3, 4))
            .build();

    svc.answerSurvey(surveyAnswer);

    // 저장 결과 확인
    SurveyAnswer savedAnswer = memoryRepository.findBySurveyAndRespondent(1L, 100L);

    assertAll(
        () -> assertEquals(100L, savedAnswer.getRespondentId),
        () -> assertEquals(4, savedAnswer.getAnswers().size()),
        () -> assertEquals(1, savedAnswer.getAnswers().get(0)),
        () -> assertEquals(2, savedAnswer.getAnswers().get(1)),
        () -> assertEquals(3, savedAnswer.getAnswers().get(2)),
        () -> assertEquals(4, savedAnswer.getAnswers().get(3))
    )
}

두 개 이상을 검증하지 않기

• 하나의 테스트에서 여러 가지를 검증하면,
  테스트가 실패했을 때 무엇이 실패했는지 확인하는 데 집중도가 떨어지게 된다.
• 하나의 테스트 메서드가 한 가지만 검증하도록 하면,
  구체적인 실패 위치를 몰라도 어떤 기능이 실패했는지 파악하기 쉽고 빠르게 고치기도 쉽다.
• 테스트 메서드가 반드시 한 가지만 검증해야하는 것은 아니지만,
  검증 대상이 명확하게 구분된다면 테스트 메서드도 구분하는 것이 유지보수에 좋다.
• 예시
  • 회원 가입 시 같은 ID가 없으면 성공적으로 가입 후 메일 전송 1) 같은 ID가 없으면 가입 성공 2) 회원 가입 시 이메일 전송

정확하게 일치하는 값으로 모의 객체 설정하지 않기

@Test
void weakPassword() {
    // 약한 암호인 경우, UserRegister가 의도한 대로 동작하는지를 확인하는 테스트
    // - "pw"를 넘겼을 때, 약한 암호인지 확인하는 코드가 아님
    // - 임의의 문자열에 대해 true를 리턴해도 이 테스트 의도에 전혀 문제되지 않음!

    // X
    // BDDMockito.given(mockPasswordChecker.checkPasswordWeak("pw")) 
    BDDMockito.given(mockPasswordChecker.checkPasswordWeak(Mockito.anyString()))
            .willReturn(true);

    assertThrows(WeakPasswordException.class, () -> {
        userRegister.register("id", "pw", "email");
    });
}

@Test
void checkPassword() {
    userRegister.register("id", "pw", "email");
    BDDMockito.then(mockPasswordChecker)
            .should()
            // .checkPasswordWeak("pw");
            .checkPasswordWeak(Mockito.anyString());
}

• 모의 객체는 가능한 범용적인 값을 사용해서 기술해야 한다.
  • 한정된 값에 일치하도록 모의 객체를 사용하면, 약간의 코드 수정만으로도 테스트가 실패할 수 있다. 이때, 테스트 코드의 일부 값을 수정하면 모의 객체 관련 코드도 수정해야 하는 번거로움이 있다.

[2jigoo]

과도하게 구현 검증하지 않기

@Test
void checkPassword() {
    userRegister.register("id", "pw", "email");

    // PasswordChecker#checkPasswordWeak() 메서드 호출 여부 검사
    BDDMockito.then(mockPasswordChecker)
            .should()
            .checkPasswordWeak(Mockito.anyString());

    // UserRepository#findById() 메서드를 호출하지 않는 것을 검사
    BDDMockito.then(mockRepository)
            .should(Mockito.never())
            .findById(Mockito.anyString());
}

• 내부 구현을 검증하면, 구현을 조금만 변경해도 테스트가 실패할 가능성이 커진다.
  • 예) 중복 ID가 존재하는지 확인 후 비밀번호 강도를 검사하는 것으로 구현을 변경하면 위 테스트는 실패한다.
• 내부 구현은 언제든지 바뀔 수 있기 때문에 테스트 코드는 내부 구현보다 실행 결과를 검증해야 한다.

// 가짜 구현으로 대체 하기 어려운 레거시 코드
public void changeEmail(String id, String email) {
    int cnt = userDao.countById(id);
    if (cnt == 0) {
        throw new NoUserException();
    }

    userDao.updateEmail(id, email);
}

@Test
void changeEmailSuccessfully() {
    given(mockDao.countById(Mockito.anyString())).willReturn(1);

    // 이메일 수정 시
    emailService.changeEmail("id", "new@somehost.com");

    // updateEmail 메서도 호출 검증
    then(mockDao)
            .should()
            .updateEmail(Mockito.anyString(), Mockito.matches("new@somehost.com"));
}

• 레거시 코드에 단위 테스트를 추가하는 경우 내부 구현을 검증해야 할 때도 있다.
• 가짜 구현으로 대체하기 어려워 위와 같이 모의 객체를 활용

기능을 검증할 수단이 구현 검증뿐이라면 모의 객체를 사용해서 테스트 코드 작성. 테스트 코드 작성 후엔 점진적으로 코드를 리팩토링하여 구현이 아닌 결과를 검증할 수 있도록 해야한다.

셋업을 이용해서 중복된 상황을 설정하지 않기

@BeforeEach와 같은 셋업 메서드를 이용해 테스트 메서드의 상황 설정을 지양한다.

• 셋업 메서드를 확인하기 위해 위아래 이동. 직관적이지 않음.
• 모든 테스트가 동일한 상황 코드를 공유하기 때문에, 조금만 변경해도 실패하기 쉬운 구조가 됨

테스트 메서드는 검증을 목표로 하는 하나의 완전한 프로그램이어야 한다. 각 테스트 메서드는 검증 내용을 스스로 잘 설명할 수 있어야 한다.

• 변경 전

  @BeforeEach
  void setUp() {
      changeService = new ChangeUserService(memeoryRepository);
      memoryRepository.save(
          new User("id", "name" "pw", new Address("서울", "북부")
      );
  }
  
  @Test
  void changeAddress() {
      changeService.changeAddress("id", new Address("서울", "남부"));
  
      User user = memoryRepository.findById("id");
      assertEquals("서울", user.getAddress().getCity());
  }

• 변경 후

  
  @BeforeEach
  void setUp() {
      changeService = new ChangeUserService(memeoryRepository);
  }
  
  @Test
  void changeAddress() {
      memoryRepository.save(
          new User("id", "name", "pw", new Address("경기", "남부")
      );
  
      changeService.changeAddress("id", new Address("서울", "남부"));
  
      User user = memoryRepository.findById("id");
      assertEquals("서울", user.getAddress().getCity());
  }