통합테스트을 좀 더 좋게 작성하기위한 사전 지식

단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 작동하는지 알 수 없다. 결국 통합테스트를 진행해야하며 단위테스트로 비즈니스로직을 확인한다 하더라도 외부의 의존성테스트를 안 할 수도 없는 노릇이다.

통합테스트의 역할

단위 테스트가 도메인 모델 및 알고리즘에 대한 테스트를 진행한다면 통합테스트는 컨트롤러를 다루는 전체적인 테스트를 진행한다. 통합테스트는 회기 방지가 단위테스트 보다 우수하고, 제품코드와의 결합도 낮아서 리팩터링 내성도 우수하다.
통합테스트는 주요흐름과 단위테스트가 다루지 못하는 기타 예외 상황을 다룬다.

빠른 실패 원칙

빠른 실패 원칙은 예기치 않은 오류가 발생하자마자 현재 연산을 중단하는 것을 의미한다. 마치 도미노를 할때 중간중간 세이프바를 두는것과 같다.

• 피드백 루프 단축: 버그를 빨리발견하여 여러 작업시간을 단축한다.
• 지속성 상태 보호: 버그는 어플리케이션의 상태를 손상시킨다. 손상이 확산되기전에 막아 놓는것

프로세스 외부 의존성의 두가지 유형

• 관리의존성: 전체를 제어할 수 있는 프로세스 외부의존성 ex) DB
• 비관리 의존성 : 전체를 제어할 수 없는 프로세스 외부 의존성 ex)SMTP 메시지 버스 등등

통합테스트에서 실제 데이터베이스를 태스트 할 수 없을땐

통합테스트에서 실제 데이터베이스를 테스트 할 수 없을때 이를태면 IT보안정책이나 버전문제 등으로 테스트를 할 수 없을때 말이다.
그럴때는 mock을 하는게 나을까? 아니다. 그렇게 되면 리팩터링 내성이 떨어지게되고 가치없는 테스트스윝이 된다. 그렇기때문에 이러한 경우에는 도메인모델 테스트에 집중하는 것이 좋다

테스트 가치가 있는 테스트만이 테스트 스위트에 존재해야한다

통합테스트 모범 사례

• 도메인 모델 경계 명시하기
• 애플리케이션 내에 계층 줄이기
• 순환 의존성 제거하기

보통 테스트에 유익한 모범 사례는 코드베이스의 상태를 개선하는 편이다.

도메인 모델 경계 명시하기

항상 도메인 모델을 코드베이스에서 명시적이고 잘 알려진 위치에 두도록 하라. 도메인 모델은 프로젝트가 해결하고자 하는 문제에 대한도메인 지식의 모음이다. 도메인 모델에 명시적 경계를 지정하면 코드의 해당부분ㅇ르 더 잘보여주고 더 잘 설명할 수 있다.

계층 수 줄이기

대부분의 프로그래머는 간접 계층을 추가해서 코드를 추상화하고 일반화 하려고 한다. 일반적인 엔터프라이즈급 애플리케이션에서 여러 계층을 쉽게 찾아볼 수 있다. 애플리케이션에 추상계층이 너무 많으면 코드베이스를 탐색하기 어렵고 아주 간단한 연산이라 해도 숨은 올직을 이해하기가 너무 어려워진다.

컴퓨터 과학의 모든 문제는 또 다른 간접 계층으로 해결할 수 있다. 간접 계층이 너무 많아서 문제가 생기지 않는다면 말이다.
- 데이빗 휠러

순환 의존성 제거하기

순환의존성은 둘 이상의 클래스가 제대로 작동하고자 직간접적으로 서로 의존하는 것을 말한다.
순환의존성의 대표적인 예는 콜백이다. 이는 어떠한 경우에는 추상 계층이 너무 많은 것과 마찬가지로 읽고 이해할때 알아야할것이 많아지고 부담스러워진다. 이는 해결책을 찾기 위한 출발점이 명확하지 않기 때문이다. 이러한 이유때문에 테스트를 작성할때 순환의존성이 있으면 인터페이스에 의존해 목을 처리해야 하는 경우가 많고 이렇게 여러 테스트 지표들이 않좋아지게된다.