개요
-
수동 테스트
테스트 담장자가 소프트웨어를 직접 실행해보고 각각의 기능을 평가하며 구현된 기능이 요구사항에 부합하는지 검증 -
자동 테스트
테스트 스크립트나 도구를 사용
// 자동 테스트 예시
public class CalculatorTest{
@Test
void add(){
//given
Calculator calculator = new Calculator();
long a = 10;
long b = 20;
// when
long result = calculator.add(a,b);
// then
assertThat(result).isEqualTo(30)
}
}JUnit 테스트 라이브러리를 이용
@Test로 특정 메소드를 테스트 메소드로 만들 수 있다.
테스트 메소드로 프로그램 전체를 실행하지 않아도 된다.
assertThat으로 테스트 수행 결과가 기댓값과 일치하는지 확인한다.
- 장점
수동 테스트와 다르게 인간의 개입이 적어 정확성이 높고, 빠르다.
하지만, 개발자의 숙련도에 따라 테스트 품질이 결정된다.
- 인수 테스트
시스템이 비즈니스 요구사항을 만족해서 소유권을 넘기기 전에 수행하는 테스트
(시스템이 비즈니스 요구사항과 일치하는가?)
수행할 테스트는 일반적으로 테스트 수행 절차와 기댓값이 적힌 체크리스트로 관리된다.
(이 체크리스트를 이용해 프로덕트를 하나하나 따져가며 요구사항에 부합하는지 판단한다.)
요구사항에 부합한다면 체크리스트에 있는 테스트를 성공, 아니면 실패로 기록
엑셀이나 테스트 관리 도구로 관리
(CASEBOOK)
최종 단계에 하는 테스트이므로 고객에게 전달하기 전 '사용자 관점'에서 전체 시스템을 검증할 수 있다.
그러나 아래와 같은 실수를 한다.
-
인수 테스트 과정의 테스트를 대부분 수동 테스트로만 구성한다.
(비용이 너무 많이 들어간다.) -
배포 후, 계속 테스트를 꾸준히 해야하는데, 프로젝트가 커질수록 기존 테스트와 누적해서 반복작업이 가능하나???
( 수동 테스트 비용이 누적된다. )
Ex) 서비스 컴포넌트를 테스트하는 테스트 코드
public class SampleUserTest{
@Test
void email_password_signUp(){
// given
UserCreateRequest userCreateRequest = UserCreateRequest.builder()
.email(...)
.password(...)
.build()
;
// when
// UserService에 주입을 한 다음, 비즈니스 로직을 실행시킨다.
UserService userService = UserService.builder()
.registerMessageSender(new DummyRegisterMessageSender())
.userRepository(userRepository)
.build();
userService.register(userCreateRequest);
// then
Optional<User> result = userRepository.findByEmail(...);
// 가입됐는지 확인한다.
assertThat(result.isEmpty()).isFalse();
// 이메일 인증이 대기 상태인지 확인한다.
assertThat(result.get.isPending()).isTrue();
}
}테스트하려는 대상 객체를 인스턴스화하고 해당 객체에 원하는 입력과 동작을 지정해 기댓값과 결과값을 비교한다.
이를 통해서 어떤 클래스나 메소드가 제대로 작동하는지, 서비스가 능동적으로 작동하는지 확인을 할 수 있다.
- 장점
시스템 변경시, 버그를 잡을 수 있다.
테스트가 누적된다.(초기 설계와 벗어난 부분이 있는지 파악을 할 수 있다.)
12.1 Regression
시스템에서 정상적으로 제공하던 기능이 어떤 배포 시점을 기준으로 제대로 동작하지 않음
(일종의 버그 상황)
회귀 버그를 방지하기 위해서는 테스트를 무조건 해야한다.
12.2 의도
개발된 메소드를 테스트에 넣어서 의도에 맞게 작동하는지 검증을 해야한다.
테스트로 의도를 드러낸다.
의도를 드러내는 테스트를 먼저 작성하고, 거기에 부합하는 내부 구현을 작성한다 = TDD
실제 코드를 작성하기 전에 해당 코드의 테스트 케이스를 먼저 작성하게 하는 개발 방법론이다.
TDD로 객체가 주어진 역할을 제대로 수행하는지 파악할 수 있다.
-
given
주어진 값 -
when
비즈니스 로직 실행 -
then
예상한 결과
12.3 레거시 코드
오래된 소프트웨어 시스템에 존재하는 코드
(단순히 테스트 루틴이 없는 코드.)
리팩토링 하기 전에 반드시 테스트 코드를 작성한다.
