단위 테스트(Unit Test)

단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행해 예상대로 동작하는지 확인하는 Test

일반적으로, 클래스 또는 메소드 수준으로 정해짐.
단위의 크기가 작을수록 단위의 복잡성이 낮아짐.
테스트 대상 단위의 크기를 작게 설정해 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성해야한다.

단위테스트는 TDD(테스트 주도 개발)와 함께 할 때 좋다.

통합 테스트(Integration Test)

통합테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈을 모아 이들의 의도대로 협력하는지 확인하는 테스트

통합 테스트는 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때 사용.
이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있다.
그러나, 통합 테스트가 응용 프로그램이 완전하게 작동하는걸 무조건 증명하지는 않는다.

장점: 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다.
단점: 단위 테스트보다 더 많은 코드를 테스트해서 신뢰성이 떨어질 수 있다.
어디서 에러가 발생했는지 확인하기 쉽지 않아 유지보수하기 힘들다.

@SpringBootTest 어노테이션을 붙여 통합테스트를 수행 가능하게 한다.

인수 테스트(Acceptance Test)

사용자 시나리오에 맞춰 수행하는 테스트

앞의 두 테스트와는 달리 비즈니스 쪽에 초점을 둔다.
프로젝트에 참여하는 사람들이 토의해 시나리오를 만들고,
개발자는 이에 의거해 코드를 작성.
개발자가 직접 시나리오를 제작할 수 있지만, 다른 의사소통 집단으로부터 시나리오를 받아 개발한다는 의미를 가진다.

인수 테스트는 애자일 개발 방법론에서 파생.
특히 XP(익스트림 프로그래밍)에서 사용하는 용어

인수 테스트는 소프트웨어 인수를 목적으로 하는 테스트.
소프트웨어 인수 전 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증 필요
소프트웨어를 인수할 때, 소프트웨어 내부 구조나 구현 방법을 고려하기 보다
실제 사용자 관점에서 테스트하는 경우가 많다.
따라서, 인수 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트이다.
실제 사용자 관점에서 테스트할 때 주로 E2E(End-to-End) 형식을 이용해 확인한다.

Java에서 RestAssured, MockMvc 같은 도구를 활용해 인수 테스트를 작성할 수 있다.

• 애자일 방법론?
  계획 -> 설계(디자인) -> 개발(발전) -> 테스트 -> 검토(피드백) 순으로 반복적 진행
  계획을 세운 후 다음 단계까지 기다려 절차대로 진행하는 폭포수 모델과는 달리
  먼저 진행 후 분석, 시험, 피드백을 통해 개선해나가는 진행모델