TestCode - 테스트코드

📌 테스트는 왜 필요할까?

• 소프트웨어 개발 과정에서 테스트는 단순한 옵션이 아닌 필수입니다. 새로운 기능 추가나, 기존 코드를 수정하는 과정에서 예기치 못한 오류가 발생할 수 있습니다. 테스트 코드는 이런 오류들을 사전에 방지하고, 코드 변경 시 회귀 오류를 최소화하는 안전망 역할을 합니다.

---

📌 테스트의 장점 :

• 신뢰성 향상 : 테스트가 있다면 코드 변경 후에도 기존 기능이 망가지지 않았는지, 신속하게 확인 가능

• 코드 이해도 증가 : 테스트는 코드의 사용 예를 보여주고 다른 사람이 보기에도 기능을 쉽게 이해하고 유지보수할 수 있게 돕습니다.

• 장기적 비용 절감 : 초반에 테스틀 작성하는 비용은 들지만, 장기적으로 오류 수정 비용을 크게 줄이고 안정적으로 시스템을 운영할 수 있다.

---

📌 단위 테스트(Unit Test)와 통합 테스트(Integration Test)

1. 단위 테스트(Unit Test)

• 목적 : 작은 단위(메서드, 클래스(Controller, Service, Repository))의 로직 검증
• 특징 : 빠르고 독립적으로 실행, Mocking 활용 가능
• 예시 : UserService 에서 사용자 조회 로직만 테스트할 때 UserRepository를 Mock으로 대체

2. 통합 테스트(Integretion Test)

• 목적 : 애플리리케이션의 여러 계층(Controller, Service, Repository, DB)과 외부 자원이 실제로 잘 동작하는지 검증

• 특징 : 실제 DB/H2, Controller 호출(MockMvc) 등을 통한 전체 흐름 검증, 실행 시간 다소 길 수 있음

• 예시 : 실제 H2 DB 연동 후 UserController로 HTTP 요청을 보내고, DB에 원하는 결과가 들어갔는지 확인

---

📌 Mocking 이란?

• Mocking은 테스트 시 외부 의존성을 가진 객체 (예 : DB, 외부 API)를 모의(Mock) 객체로 대체하여 테스트 대상 로직만 검증하는 기법입니다.

왜 Mocking을 할까?

• 실제 DB나 외부 API 없이도 테스트 가능 -> 빠르고 안정적인 테스트
• 특정 조건 (성공, 실패)을 쉽게 시뮬레이션 가능
• 단위 테스트에서 서비스 로직만 집중 검증

예시 : UserService 테스트 시 UserRepository 를 Mock 으로 만들어 "특정 속성으로 조회아면 항상 같은 User를 반환" 하도록 설정하면, DB없이 로직만 테스트할 수 있습니다.

📌 FIRST 원칙

• 좋은 테스트는 다음과 같은 FIRST 원칙을 따라야 합니다.
• 이 원칙을 지키면 테스트 코드가 유지보수하기 쉬워지고, 개발 생산성이 증가합니다.
  • 1. Fast(빠르게) : 테스트는 짧은 시간 안에 실행되어야 한다.
  • 2. Independent(독립적) : 각 테스트는 다른 테스트에 영향을 받지 않고, 독립적으로 수행 가능해야 한다.
  • 3. Repeatable(반복 가능) : 언제나 동일한 결과를 얻을 수 있어야 합니다.
  • 4. Self-checking(자기 검증) : 테스트 결과가 성공/실패를 명확히 나타내어 사람이 추가로 판별할 필요 없어야 합니다.
  • 5. Timely(적시에 작성) : 실제 코드를 구현하기 전에 혹은 최소한 함께 작성하여 가치 있는 피드백을 얻어야 합니다.

---

• 아래로 갈수록 테스트가 많고, 비용이 적음, 자동화 난이도 낮음
• 위로 갈수록 테스트가 적고, 비용이 높음, 자동화 난이도 높음

📌 BDD와 TDD

• TDD(Test Driven Development) 와 BDD(Behavior Driven Development) 는 테스트 개발 과정의 핵심요소로 자리 잡게 만든 철학적인 방법론이다.

TDD (테스트 주도 개발)

• 등장 배경

  • 개발을 진행하다보면 코드를 끝까지 작성한 후에야 "정말 작동하는지"를 확인하는 테스트를 진행
  • 계속 반복하다보면 오류를 수정하고나서 내가 무엇을 만들어야 하는지 잊어버리고 일단 만들다 설계에서 벗어나는 일이 비일비재 하다
  • 위와 같은 상호아을 해결하기 위해 먼저 설계 후 잘 작동하는 코드를 작성하는 패러다임 TDD가 나왔습니다.

• 개념

  • Test(실패하는 테스트 작성) → Code(테스트 통과를 위한 최소한의 코드) → Refactor(코드 개선)

• 효과

  • 기능 구현 이전에 테스트를 작성함으로써, 구현 대상과 범위를 명확하게 정의하고, 불필요한 로직을 만듲리 않게 도와줍니다.

BDD (행위 주도 개발)

• 등장 배경

  • TDD는 개발자들끼리의 의사소통이 잘 되지만 비 개발자에게는 많이 어렵습니다.
  • 또한 협업을 진행한다면 비 개발자 인원이 더 많으면 프로젝트를 이끌어 가는 기획자의 의견은 중요합니다.
  • 테스트를 사람이 읽을 수 있는 언어로 작성하기 시작해 개발자와 비 개발자가 협어이 원핳해집니다.

• 개념

  • 사용자의 행위에 초점을 맞추어 given - when - then 형태로 테스트 시나리오 작성

• 효과

  • 비 개발자, 기획자, 개발자 모두가 이해하기 쉬운 시나리오로 테스트를 작성하여 커뮤케이션 비용 감소와 명확한 요구사항 파악 가능

---

TDD VS BDD

특징	TDD	BDD
초점	코드를 올바르게 작성하기 위한 기술적 기반	비즈니스 요구사항을 기반으로 시스템 동작 정의
언어	개발자 중심, 기술적인 테스트 코드	비개발자도 이해할 수 있는 행동 기반 서술
목표	"내 코드가 제대로 작동하나?"	"사용자와 비즈니스 요구를 충족하는가"
예시	assertEquals(add(2,3), 5)	given two value when insert function then add two value (유저가 준 두개의 값을 입력해 주면 더하는 기능을 만들어주세요.)

• TDD 는 로직이 중요한 기능 (알고리즘, 유틸리티, API 등) 을 개발할 때 효과적입니다.

• BDD 는 사용자의 기대 동작이 중요한 경우(웹 에플리케이션, UI/UX 중심 개발) 에 적합합니다.

• TDD는 코드 품질을 높이고, BDD는 요구사항을 정확하게 반영하는 데 유리합니다.