테스트 종류
테스트 피라미드
- 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 단위 테스트
메서드 하나같이 코드의 작은 부분을 테스트
- 실행가능한 가장 작은 소프트웨어를 테스트
- 가장 간단하고 명확하게 작성 가능하다.
- 각 테스트 유닛은 반드시 독립적이어야 한다.
- 장점
- 코드를 수정하거나 기능을 추가할 때 수시로 빠르게 검증할 수 있다.
- 리팩토링시 안정성 확보
- 개발 및 테스팅에 대한 시간과 비용 절감
어플리케이션 테스트 작성 방법
Test Driven Development (TDD)
반복 테스트를 이용한 소프트웨어 방법론
특징
- 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
- 짧은 개발 주기의 반복에 의존하는 개발 프로세스
- 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 두었다.
- 미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나
- 추가 요구사항이 생기더라도 실시간으로 반영 가능
- 단순한 설계를 장려한다.
개발 주기
- RED : 실패하는 테스트 코드 작성
- GREEN : 테스트 코드를 통과시키기 위한 최소 실제 코드 작성
- BLUE : 중복 코드 제거, 일반화 등 리팩토링 수행
일반 개발 방식
요구사항 분석 → 설계 → 개발 → 테스트 → 배포
단점
- 개발을 느리게 하는 잠재적 위험
- 어느 프로젝트든 초기 설계가 완벽할 순 없다. 재설계로 인한 코드 수정 과정에서 불필요한 코드가 남거나 중복처리될 가능성이 있다.
- 자체 버그 검출 능력 저하
- 작은 부분의 기능 수정에도 모든 부분을 테스트해야하기 때문
- 소스코드의 품질 저하
- 어디서 버그가 발생할지 모르기 때문에 잘못된 코드도 고치지 않으려는 현상
- 자체 테스트 비용 증가
- 작은 수정에도 모든 기능을 다시 테스트해야한다
TDD 개발 방식
테스트 코드 작성 후 실제 코드 구현
장점
- 디자인 단계에서 프로그래밍 목적을 반드시 미리 정의해야 한다.
- 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피하고 정확한 요구 사항에 집중할 수 있다.
- 테스트 케이스 작성으로 설계가 개선되어 재설계 시간이 절감된다.
- 코드의 버그가 줄고, 깔끔한 코드를 작성할 수 있다.
단점
- 생산성 저하
- 처음부터 2개의 코드를 짜고 중간중간 테스트를 하며 고쳐나가야 한다.
- 일반적인 개발 방식에 비해 10~30% 시간을 더 쓴다.
- 러닝 커브
- 구조에 얽매인다.
- 실제 코드가 더 중요한 상황임에도 테스트 원칙 때문에 쉽기 넘어가지 못하는 경우
구현 방식
-
가짜로 구현하기
- 아무 값(ex> 상수)이나 반환하기
- 최대한 빨리 테스트를 통과하는 것이 목표
- 복잡한 코드를 단계로 잘게 쪼개어 TDD로 개발하는 방법
@Test
public void 나이구하기() {
int age = calculateAge(2000);
assertThat(age).isEqualTo(23);
}
public int calculateAge(int birthYear) {
return 23;
}
-
삼각 측량
- 값이 다른 여러 테스트를 작성하고 일반화하는 과정
- 테스트 예시가 2개 이상일 경우
@Test
public void 나이구하기() {
int age1 = calculateAge(2000);
int age2 = calculateAge(1995);
assertThat(age1).isEqualTo(23);
assertThat(age2).isEqualTo(28);
}
-
명백하게 구현하기
- 가짜 구현이나 삼각 측량 방법을 사용하지 않고 바로 정답을 구현하는 방식
- 나이를 구하는 문제와 같이 바로 구현 가능한 경우
public int calculateAge(int birthYear) {
LocalDate now = LocalDate.now();
int currentYear = now.getYear();
return currentYear - birthYear + 1;
}
출처