• 테스트 코드를 작성함에 있어서 테스트 하는 목적에 따라 어떤 테스트가 있는지 확인해보고 그에 따라 테스트를 작성해 본다.

참고

• 단위 테스트 vs 통합 테스트 vs 인수 테스트
• 소프트웨어 테스트 안티 패턴-1
• 소프트웨어 테스트 안티 패턴-2

• 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자 관점에서 테스트를 진행하고, 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트 박스 테스트이다.

• 개발자가 변경할 수 없는 부분까지 묶어서 검증하려고 하는 경우 사용한다.
• 단위 테스트와 다르게 발견하기 어려운 버그를 찾을 수 있다는 장점이 있다.
• 통합 테스트의 단점은 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신뢰성이 떨어질 수 있다. 또, 어디서 에러가 발생했는지 확인하기 쉽지 않아 유지보수가 쉽지 않다.

사용자 스토리(시나리오)에 맞춰 수행하는 테스트로 위의 두 테스트와 달리 비즈니스 쪽에 초점을 두어, 다른 의사소통 집단으로부터 시나리오를 받아(인수) 개발하는 방식이다.

익스트림 프로그래밍(XP)에서 사용하는 용어로 시나리오가 정상적으로 동작하는지 테스트 하는 방식 소프트웨어를 인수하기 전에 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증이 필요하다. 인수 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트이다. 실제 사용자 관점에서 테스트 할 때 주로 E2E 형식을 이용해서 확인한다.

• Persistence, DomainService, Service, Presentation 으로 구성되어 있는 프로젝트를 각 레이어 별로 테스트 코드를 작성한다.

• Entity에 대한 생성 및 객체 비교(equals, hashCode)에 대한 테스트를 진행한다.

• Repository를 Wrapping한 클래스로 구현 기능에 대한 기능 테스트와 예외테스트를 진행한다.

• 둘 이상의 엔티티를 비즈니스 기능으로 묶은 BusinessService 클래스로 관련 기능과 해당 레이어의 예외 테스트에 대해서 테스트를 진행한다.

• API 호출 기능을 하는 레이어로 해당 레이어의 기능과 예외 테스트를 진행한다.
• 추가적으로 요청 값에 대한 Validation, AOP 기능에 대해서도 테스트를 진행한다.

• 인수 테스트를 작성하기 위한 라이브러리
• rest-assured

서비스의 시작점 부터 동작할 수 있는 플로우(시나리오)를 만들고, 그에 따라 순차적으로 테스트가 이루어지는 인수 테스트를 작성한다.

행위 주도 개발 테스트 작성 스타일은 given, when, then 이라는 테스트 메서드 프로세스를 기본으로 사용한다.

• BDD 배우기
• BDDMockito