[워밍업 클럽 3기] BE클린코드&테스트코드 Day9

🟡 오늘의 목표 진도

---

섹션1. Intro

 - 강의 소개

  - 어떻게 학습하면 좋을까?

섹션2. 테스트는 왜 필요할까?

 - 테스트는 왜 필요할까?

섹션3. 단위 테스트

 - 샘플 프로젝트 소개 & 개발 환경 안내

 - 프로젝트 세팅

 - 수동 테스트 VS 자동화된 테스트
 - JUnit5로 테스트하기

 - 테스트 케이스 세분화하기

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

 - 키워드 정리

섹션4. TDD: Test Driven Development

 - TDD: Test Driven Development

 - 키워드 정리

섹션5. 테스트는 []다.

 - 테스트는 []다.

 - DisplayName을 섬세하게

 - BDD 스타일로 작성하기

 - 키워드 정리

 

 

🟠 공부 정리

---

1. 테스트는 왜 필요할까

 테스트는 귀찮지만, 빠른 피드백, 자동화, 안정감을 위해 필수적

 

 ✔  테스트 코드를 작성하지 않는다면?

 

• 변화가 생길 때마다 모든 케이스를 고려해야 함
• 팀원들이 동일한 고민을 반복해야 함
• 소프트웨어의 안정성을 보장하기 어려움

 

✔  테스트 코드가 병목이 된다면?

 

• 프로덕션 코드의 안정성을 확보하기 어려움
• 테스트 코드 자체가 유지보수의 부담이 될 수 있음
• 잘못된 검증으로 인해 신뢰성이 낮아질 위험이 있음

 

✔   올바른 테스트 코드란?

 

• 자동화된 빠른 피드백으로 버그를 조기에 발견하고, 수동 테스트 비용 절감.
• 빠른 소프트웨어 변화에 유연하게 대응할 수 있도록 지원.
• 팀의 집단 지성을 극대화하여 개발 효율성 향상.
• 단기적으로는 느려 보일 수 있지만, 장기적으로 가장 효율적인 개발 방식.

 

2. 단위 테스트

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

 ✔  검증 속도가 빠르고, 안정적

 ✔  JUnit 5 : 단위 테스트를 위한 테스트 프레임워크

 ✔  AssertJ : 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리 (풍부한 API, 메서드 체이닝 지원)

 ✔ 테스트 케이스 세분화

• 해피 케이스, 예외케이스 → 경계값 데스트 (범위[이상, 이하, 초과, 미만], 구간, 날짜 등)
• 테스트하기 어려운 영역을 구분하고 분리하기
  • 테스트하기 어려운 영역
    • 관측할 때마다 다른 값에 의존하는 코드
    • ↪ 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
    • 외부 세계에 영향을 주는 코드
    • ↪ 표준 출력, 메시지 발송, 데이터베이스에 기록하기 등

3. TDD

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

 ✔ 실패하는 테스트 작성(RED) → 테스트 통과 최소한의 코딩(GREEN) → 구현 코드 개선 테스트 통과 유지 (REFACTOR)

 ✔ 先 funtion 구현, 後 TEST 작성 시

• 테스트 자체의 누락 가능성
• 특정 테스트 케이스만 검증할 가능성 (해피 케이스)
• 잘못된 구현을 다소 늦게 발견할 가능성

✔ 先 TEST 작성, 後 funtion 구현

• 유연하며 유지보수가 쉬운 코드로 구현할 수 있게 함
• 쉽게 발견하기 어려운 엣지(Edge) 케이스를 놓치지 않게 해줌
• 구현에 대한 빠른 피드백을 받을 수 있음
• 과감한 리팩토링이 가능

4. 테스트는 문서다

✔ 프로덕션 기능을 설명하는 테스트 코드 문서

✔ 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완

✔ 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있음

✔ DisplayName을 섬세하게

• 명사의 나열보다 문장으로
• "~테스트" 지양하기
• 테스트 행위에 대한 결과까지 기술하기
• 도메인 용어를 사용하여 한층 추상화된 내용을 담기 (메서드 자체의 관점보다 도메인 정책 관점으로)

@DisplayName("음료 1개 추가 테스트") // x
@Test
void add() {
    ...(생략)
}


@DisplayName("음료를 1개 추가하면 주문 목록에 담긴다.") // o
@Test
void add() {
    ...(생략)
}

 ✔  BDD (Behavior Driven Development)

• TDD에서 파생된 개발 방법
• 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트 한다
• 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장

 

 

🔵 공부 후 나의 생각 

---

오늘 테스트에 대해 다시 공부하면서,

테스트 코드의 필요성과 역할을 더 깊이 이해할 수 있었다.

 

테스트가 없다면 코드가 변경될 때마다

모든 가능성을 수동으로 점검해야 하고,

팀원들 모두가 같은 고민을 반복해야 한다.

결국, 빠르게 변화하는 소프트웨어에서 안정성을 유지하기가 어려워진다.

 

반면, 테스트 코드가 잘못 작성되면 유지보수가 어려워지고,

오히려 개발 속도를 저해할 수도 있다.

 

따라서 중요한 것은 효율적인 테스트 코드 작성이다.

자동화된 테스트를 통해 빠르게 버그를 찾아낼 수 있고,

불필요한 수동 테스트를 줄이며, 코드 변경에도 유연하게 대응할 수 있다.

 

당장은 느려 보일 수 있지만, 장기적으로 보면 결국 가장 빠르고 안정적인 개발 방식이라는 걸 다시 한 번 실감했다.

 

 

* 현재 인프런 워밍업 클럽에 참여하여 아래 강의 수강 중입니다.

https://www.inflearn.com/roadmaps/5699

클린 코드 & 테스트 코드 가이드 로드맵 로드맵 - 인프런

https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboard

Practical Testing: 실용적인 테스트 가이드 강의 | 박우빈 - 인프런