테스트 종류

테스트 피라미드

• Google Test Automation Conference에서 제안
• 전체 테스트 비중을 피라미드 그림과같은 수치로 구현하는 것이 권장된다.
  • End-To-End Testing (UI Testing) 10%
  • Integration Testing 20%
  • Unit Testing 70%
• 테스트 단위가 쪼개질수록 어느 부분에서 에러가 발생했는지 더 찾기 쉬워진다.

End-To-End Test (UI Test) 종단간 테스트

사용자와 어플리케이션의 상호작용이 잘 이루어지는지 테스트

• 실제 프로그램을 사용하는 상황 테스트
  • 브라우저 창에서 특정 기능을 실행하고 화면상에서 결과를 확인하는 테스트 방식
• 소프트웨어 내부 구조보다는 비즈니스에 초점을 두어 시나리오대로 잘 동작하는지 확인
• Acceptance test(인수 테스트)와 같은 의미로 사용된다.
  • 소프트웨어 인수를 위해 사용자 시나리오대로 테스트

Integration Test 통합 테스트

서로 다른 시스템들의 상호작용이 잘 이루어지는지 테스트

• 최소 2개 이상의 클래스 혹은 서브 시스템의 결합을 테스트하는 방법
  • ex> 내 어플리케이션이 DB와 잘 연동되는지
• Postman, httpie (client tool) 사용
• 내가 client(프론트엔드)인양 백엔드 서버에 요청을 보내고 응답을 받는다.
• 프론트엔드, 백엔드 모두 완성된 상태가 아니어도 각각 따로 테스트할 수 있다.

Unit Test 단위 테스트

메서드 하나같이 코드의 작은 부분을 테스트

• 실행가능한 가장 작은 소프트웨어를 테스트
• 가장 간단하고 명확하게 작성 가능하다.
• 각 테스트 유닛은 반드시 독립적이어야 한다.
• 장점
  1. 코드를 수정하거나 기능을 추가할 때 수시로 빠르게 검증할 수 있다.
  2. 리팩토링시 안정성 확보
  3. 개발 및 테스팅에 대한 시간과 비용 절감

어플리케이션 테스트 작성 방법

• 스프링 프로젝트 테스트 방법

Test Driven Development (TDD)

반복 테스트를 이용한 소프트웨어 방법론

특징

• 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
• 짧은 개발 주기의 반복에 의존하는 개발 프로세스
• 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 두었다.
  • 미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나
  • 추가 요구사항이 생기더라도 실시간으로 반영 가능
• 단순한 설계를 장려한다.

개발 주기

1. RED : 실패하는 테스트 코드 작성
2. GREEN : 테스트 코드를 통과시키기 위한 최소 실제 코드 작성
3. BLUE : 중복 코드 제거, 일반화 등 리팩토링 수행

일반 개발 방식

요구사항 분석 → 설계 → 개발 → 테스트 → 배포

단점

1. 개발을 느리게 하는 잠재적 위험
   • 어느 프로젝트든 초기 설계가 완벽할 순 없다. 재설계로 인한 코드 수정 과정에서 불필요한 코드가 남거나 중복처리될 가능성이 있다.
2. 자체 버그 검출 능력 저하
   • 작은 부분의 기능 수정에도 모든 부분을 테스트해야하기 때문
3. 소스코드의 품질 저하
   • 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려는 현상
4. 자체 테스트 비용 증가
   • 작은 수정에도 모든 기능을 다시 테스트해야한다

TDD 개발 방식

테스트 코드 작성 후 실제 코드 구현

장점

1. 디자인 단계에서 프로그래밍 목적을 반드시 미리 정의해야 한다.
   • 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피하고 정확한 요구 사항에 집중할 수 있다.
2. 테스트 케이스 작성으로 설계가 개선되어 재설계 시간이 절감된다.
3. 코드의 버그가 줄고, 깔끔한 코드를 작성할 수 있다.

단점

1. 생산성 저하
   • 처음부터 2개의 코드를 짜고 중간중간 테스트를 하며 고쳐나가야 한다.
   • 일반적인 개발 방식에 비해 10~30% 시간을 더 쓴다.
2. 러닝 커브
3. 구조에 얽매인다.
   • 실제 코드가 더 중요한 상황임에도 테스트 원칙 때문에 쉽기 넘어가지 못하는 경우

구현 방식

1. 가짜로 구현하기

   • 아무 값(ex> 상수)이나 반환하기
   • 최대한 빨리 테스트를 통과하는 것이 목표
   • 복잡한 코드를 단계로 잘게 쪼개어 TDD로 개발하는 방법

   @Test
   public void 나이구하기() {
   	// given
   
   	// when
   	int age = calculateAge(2000);
   
   	// then
   	assertThat(age).isEqualTo(23);
   }

   public int calculateAge(int birthYear) {
   	return 23;
   }

2. 삼각 측량

   • 값이 다른 여러 테스트를 작성하고 일반화하는 과정
   • 테스트 예시가 2개 이상일 경우

   @Test
   public void 나이구하기() {
   	// given
   
   	// when
   	int age1 = calculateAge(2000);
   	int age2 = calculateAge(1995);
   
   	// then
   	assertThat(age1).isEqualTo(23);
   	assertThat(age2).isEqualTo(28);
   }

3. 명백하게 구현하기

   • 가짜 구현이나 삼각 측량 방법을 사용하지 않고 바로 정답을 구현하는 방식
   • 나이를 구하는 문제와 같이 바로 구현 가능한 경우

   public int calculateAge(int birthYear) {
   	LocalDate now = LocalDate.now();
   	int currentYear = now.getYear();
   	return currentYear - birthYear + 1;
   }

---

출처

• Unit Test
• [TIL] Unit test, Integration test, e2e test 그리고 TDD
• [TEST] 📚 TDD 방법론 (테스트 주도 개발) 정리
• [TDD] 단위 테스트와 TDD(테스트 주도 개발) 프로그래밍 방법 소개 - (1/5)