테스트 코드 유지보수 해보기 2

이전 포스팅에 이어 테스트 코드 유지보수를 이어나가 보겠습니다.

이전 포스팅에서 적용한 것들은 다음과 같습니다.

• test datasource 설정
• schema.sql, data.sql 추가

이렇게 했을 때, 마지막 테스트 수행 결과는 다음과 같았습니다.

 

이전 포스팅에서의 마지막 테스트 결과

 

실패하는 테스트 케이스의 원인은 다음과 같았습니다.

• 테스트 예상 결과가 다른 경우 (expect ≠ result)
• 테스트 실행 중 에러가 발생한 경우

각 케이스 별로 살펴보겠습니다.

 

테스트 예상 결과가 다른 경우

기존에 작성했던 테스트 결과 대로 동작하지 않는 경우입니다.

해당 케이스들 중 첫번째는 특정 기능(ex. 알림)에 대한 테스트 케이스들이었습니다.

주문에 대한 알람 기능을 예로 들었을 때, 기존에 개발된 형상은 고객이 주문을 하면 고객도 알림을 받는 형태였고, 테스트 코드의 예상 결과는 고객을 제외한 대상자들이 알림을 받아야 했습니다.

이 경우는 기존에 개발된 기능들이 잘못 동작하고 있는지 아니면 기존에 작성된 테스트 코드의 결과가 잘못 작성되었는지 확인이 필요하였습니다.

해당 기능에 대한 기획서를 확인해본 결과, 테스트 코드의 예상 결과가 옳다는 것을 알 수 있었습니다.

그래서 기획서에 작성된 요구사항을 바탕으로 기존 기능들을 개선하였습니다.

 

개선 후 테스트 결과

 

나머지 통과하지 못하는 케이스는 JPA의 잘못된 사용 사례입니다.

@Test
@Rollback
public void should_saleRecordIsPresent_when_create() {
    SaleRecord saleRecord = new SaleRecord(1L,
                                           ZonedDateTime.now(),
                                           2L,
                                           3L,
                                           ZonedDateTime.now(),
                                           ZonedDateTime.now(),
                                           null,
                                           null,
                                           null);

    saleRecordRepository.save(saleRecord);

    Long id = saleRecord.getId();

    em.clear(); // flush가 없다

    Optional<SaleRecord> byId = saleRecordRepository.findById(id);

    Assert.assertEquals(byId.isPresent(), true);
}

보시는 바와 같이, 코드에서 repository를 통해 save() 후 flush를 하지 않고 영속성 컨텍스트를 clear() 하고 있습니다.

flush()를 해줘야 영속성 컨텍스트의 변경사항이 반영될텐데, 해당 부분을 빠트린 케이스입니다.

이 부분을 추가해주니 해당 테스트 케이스는 통과했습니다.

 

개선 후 테스트 결과

 

여기까지가 테스트 결과가 예상 결과와 다른 테스트 케이스를 개선한 내용이었습니다.

다음 케이스에 대한 분량이 다소 많을 것 같아 다음 포스팅에서 진행하겠습니다 :)