[워밍업 클럽 스터디 2기 - BE] (클린코드, 테스트코드) 3주차 발자국

인프런 워밍업 클럽 스터디 2기 - 백엔드 클린코드, 테스트 코드(Java, Spring Boot)
Practical Testing: 실용적인 테스트 가이드
해당 강의를 학습하며 정리하는 내용입니다.

2주차 발자국에 이어서 이번주도 배운 내용을 정리하고 회고를 작성한다.

이번주는 Practical Testing: 실용적인 테스트 가이드를 수강을 시작했다. 평소에도 테스트 코드를 작성해야 좋다 라는건 알고 있었지만 각종 핑계로 작성을 잘 안했었는데, 이번 강의를 통해 테스트 코드를 잘 작성하는 습관을 기르고자 한다.

왜 테스트 코드를 사용할까?

점점 기능을 추가할 때마다 새로운 사람들이 새로운 수동 테스트를 진행하고, 이전 기능이 잘 동작하는지 이전 테스트도 또 진행 해야한다.

그럼 시간이 지날수록

커버할 수 없는 영역 발생
경험과 감에 의존
늦은 피드백
유지보수 어려움
결국 소프트웨어 신뢰 ↓

라는 결과가 나타난다.

그래서 테스트 코드로 얻고자 하는 것은

빠른 피드백
자동화
안정감

이다.

테스트 코드는 ~~귀찮다~~ → 귀찮지만 해야한다.

단위 테스트

작은 코드 단위를 독립적으로 검증하는 테스트

작은 → 클래스 or 메서드
다른 코드에 의존적이지 않는
검증 속도가 빠르고, 안정적인

테스트 코드 세분화

해피케이스만 생각하지 말자. 예외 케이스도 검증해야 한다.

경계 값 : 범위(이상, 이하, 초과, 미만), 구간, 날짜 등

테스트 하기 어려운 영역을 분리

현재 시간 : 이건 테스트 할 때마다 바뀌는 값..

관측할 때마다 다른 값에 의존하는 코드
- 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
외부 세계에 영향을 주는 코드
- 표준 출력, 메시지 발송, 데이터 베이스에 기록 등

Order order = cafeKiosk.createOrder(LocalDateTime.of(2024, 10, 13, 10, 0));

이렇게 테스트하기 어려운 값들을 외부에서 받아오도록 분리하면 테스트가 가능해진다.

[CafeKiosk 요구조건 추가 - 특정 시간에만 주문 가능 - 테스트하기 어려운 영역을 분리하기](https://github.com/iamminseongKim/PracticalTesting/commit/4cbb22efb698f77796bdc52c84237d2bf61d4c2c)

TDD

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

Red - Green - Refactor 단계 개발

Red : 실패하는 테스트 작성
Green : 테스트 통과를 위한 최소한의 코딩
Refactor : 구현 코드 개선, 테스트 통과 유지

테스트는 [문서]다.

프로덕션 기능을 설명하는 테스트 코드 문서
다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완
어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다.

BDD : Behavior Driven Development

Given / When / Then

Spring & JPA 기반 테스트

Layered Architecture

관심사의 분리를 위해 레이어를 분리

A모듈과 B모듈이 만나서 AB, BA, C? 뭐가 나올지 모른다. 통합 테스트가 필요

Persistence Layer 테스트

쿼리를 테스트. 스프링 서버를 띄워서 테스트해야 하지만 계층을 분리해서 테스트 하기 때문에 일종의 단위 테스트 성격을 가지고 있다.

@DataJpaTest : @SpringBootTest 에서 JPA 관련 기능만 올려서 빠르게 테스트 할 수 있도록 도와줌. 하지만 @Transactional이 들어가 있기 때문에, 테스트 시 이 점을 고려하고, 이해하고 사용해야함.

리스트 테스트 할 때 팁 : size를 먼저 체크하고, extracting&contain 으로 안에 내용물을 검증

Business Layer

비즈니스 로직을 구현하는 역할
Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)를 통해 비즈니스 로직을 전개시킨다.
트랜잭션을 보장해야 한다.

[CafeKiosk - Business Layer 테스트 (1)](https://github.com/iamminseongKim/PracticalTesting/commit/70a421e2eec5bb2eedafea368f08148ac486c3cb)
[CafeKiosk - Business Layer 테스트 (2)](https://github.com/iamminseongKim/PracticalTesting/commit/779e2c0ac4a92a317dc96a5cd52dea6934518b1a)
[CafeKiosk - Business Layer 테스트 (3)](https://github.com/iamminseongKim/PracticalTesting/commit/ab172150610a70445e19f2a7b8ab587db63e43f5)

미션

readable code때 사용한 지뢰찾기/키오스크 둘 중 하나에 대한 test코드를 작성해보는 미션이였다.

미션을 하면서 내가 작성한 테스트 코드가 이게 진짜 잘 되는지 아직 감이 살짝 안 오긴 한다. 이건 경험의 문제 같고 아직 느끼지 못하는 것 같지만, 꾸준히 작성해보려 한다.

그리고 미션을 하면서 다른 분들의 코드를 보는데 jacoco라는 테스트 커버리지 도구가 있어서 이것도 사용해 보았다.

jacoco를 사용하니깐 테스트가 어디가 진행 됐고, 어딘 안됐고 이걸 시각적으로 볼 수 있는데, 이걸 보니깐 또 다른 게임을 하는 것 같아서 매우 재밌었다. 그리고 이번 미션이 스프링이 아니라 순수 자바로 된 코드를 테스트 하는 것이기 때문에 단위 테스트를 모두 작성해서 커버리지를 90퍼센트 이상 찍게 되었다.

회고

이번주는 드디어 내가 이 워밍업 클럽을 신청한 이유인 테스트 코드에 대해 배울 수 있게 되어서 좋았다.

현재 내 실무에서는 테스트를 잘 작성하지 않는 환경이라 테스트에 대한 갈망도 있었고, 호기심도 있었다.

이번주는 테스트 코드가 이런거구나~ 정도를 학습하고 이해했다.

다음주는 이제 실질적으로 자주 사용하는 스프링 환경에서 테스트 코드를 작성하는 방법 같은걸 배우니 더 집중해서 학습해야 할 듯 하다.