[테스트] 단위 테스트와 TDD

Future·2024년 5월 19일

목록 보기

1/1

인프런 박우빈님 Practical Testing: 실용적인 테스트 가이드 강의 정리입니다

강의를 사게 된 이유

이 강의를 사게 된 이유를 한번 이야기 해볼까 한다.
동아리 웹사이트를 만들면서, 처음 제대로 만들어보는 서비스다보니, 그리고 배포에 혈안이 되어 있어 테스트 코드를 짜지 않았다.

어떤 기능을 개발하거나, 리팩토링을 할 때, 관련된 기능을 postman으로 테스트해왔었다.
테스트 플로우가 정해져 있는 기능도 있었는데, 가끔 그 기능을 테스트할 때, 사람인지라 테스트를 완벽하게 진행하지 못할 때도 있었다.
그리고 관련 없어 보였던 기능에 문제가 생기는 경우도 많았다.

개발이 완료되고 배포 후... 소소한 에러를 잡고, 기능을 고쳐 재배포할 때마다 내가 알지 못하는 부분에서 어떤 에러가 터질 수도 있다는 불안감에 휩싸였다.

앞으로 유지보수 + 새로운 기능 개발을 후배들이 할텐데, 테스트 코드가 없어, 유지보수가 너무 힘들 것 같다는 생각이 들었다.

안정성있고 탄탄한. 유지보수 좋은 개발에 대한 욕구가 생겼다.

테스트는 왜 필요할까 ?

테스트 코드를 작성하지 않을 때 생기는 문제점
1. 변화가 생기는 매순간마다 발생할 수 있는 모든 케이스를 고려해야 한다.
2. 변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야 한다.
3. 소프트웨어 안정성을 보장할 수 없다.

단위 테스트

작은 코드 단위(클래스 or 매서드)를 독립적으로 검증하는 테스트이다.
**외부 의존 상황을 제외하고 딱 해당 클래스나 매서드만 테스트
-> 검증 속도가 빠르다.

테스트 케이스 세분화 하기

프로덕트 코드를 짤 때, 스스로 이런 질문을 던져야 한다.
"암묵적이거나 아직 드러나지 않은 요구사항이 있는가?"
이 질문을 통해 아래와 같이 테스트 케이스를 세분화 하는 것이 중요하다.

ex) 음료 주문 테스트 세분화
1. 해피케이스 - 아메리카노를 세 잔 주문한다
2. 예외케이스 - 아메리카노를 -1잔 또는 0잔 주문한다.

테스트하기 어려운 요소 분리

테스트하기 어려운 형태의 코드는 다음과 같은 것들이 있다.

위와 같은 요소들은 외부에서 주입하는 형태로 분리하는게 좋다.
외부로 분리할수록 테스트 가능한 코드가 많아진다.

ex) Order (주문) 클래스에서 주문을 생성하는 매서드
public static Order create(List<Product> products){
        return Order.builder()
                .orderStatus(OrderStatus.INIT)
                .products(products)
                .registeredDateTime(LocalDateTime.now())
                .build();
    }
-> registeredDateTime은 주문 등록 시간이라 LocalDateTime.now()를 해도 상관 없어 보인다. 하지만, 막상 이 코드를 테스트하려면, 이 부분 때문에 테스트를 작성하기가 어렵다. LocalDateTime.now()는 계속 바뀌는 값이기 때문이다.

아래와 같이 수정하면 테스트하기 어려운 요소를 분리하여 테스트 가능한 코드로 만들 수 있다.
public static Order create(List<Product> products, LocalDateTime registeredDateTime){
        return Order.builder()
                .orderStatus(OrderStatus.INIT)
                .products(products)
                .registeredDateTime(registeredDateTime)
                .build();
    }

TDD

프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론

기능을 먼저 구현하고 테스트를 작성할 경우에 다음과 같은 문제점이 발생할 수 있다.

하지만 TDD를 적용하면, 이러한 문제를 커버할 수 있다.

개인적으로 프로덕트 코드 작성 후에 테스트 코드를 작성하면, 테스트를 누락하거나, 유지보수가 어려운 코드를 짤 위험이 있다는 점이 공감이 된다.

테스트는 문서다

테스트 코드는 프로덕션 코드의 기능을 설명하는 문서이다.
다양한 테스트 케이스를 통해 프로덕션 코드를 이해할 수 있고, 어느 한 사람이 과거에 경험했던 고민의 결과를 모두가 공유할 수 있다.

DisplayName 섬세하게 작성하기

@DisplayName()을 완성된 문장 형태로 섬세하게 작성하는 것이 좋다.
도메인 용어를 사용하여 테스트 행위에 대한 결과를 작성하도록 한다.

여기에서 실패한다 라는 말은 오직 테스트 관점에서 테스트가 실패한다는 것이기 때문에 적절하지 않다. 실제 도메인 관점에서 작성하는게 좋다.