[Unit Testing] 2장 단위테스트란 무엇인가?

단위테스트 : 생산성과 품질을 위한 단위테스트 원칙과 패턴 (블라디미르 코리코프 저)
'2장_ 단위 테스트란 무엇인가' 부분을 읽고 정리한 내용입니다.

모든 소스코드는 이곳에서 확인할 수 있습니다.

 

단위 테스트의 정의

단위테스트는

1. 작은 코드 조각을 검증하고
2. 빠르게 수행하고
3. 격리된 방식으로 처리하는 자동화된 테스트이다.

그렇다면, 이중 세 번째 "격리된 방식으로 처리하는" 부분에서의 격리는 정확히 무엇일까?

고전파와 런던파의 주장에 대해 정리해보자.

격리 문제에 대한 런던파의 접근

런던파에서 주장한 "격리"는 테스트 대상 시스템을 협력자에게서 격리하는 것을 일컫는다.

즉, 하나의 클래스가 다른 클래스 또는 여러 클래스에 의존하면 이 모든 의존성을 테스트 대역으로 대체해야 한다는 것이다.

 

 

이 방식의 이점

1. 테스트가 실패하면 코드베이스의 어느 부분이 고장 났는지 확실히 알 수 있으며,
2. 객체 그래프(같은 문제를 해결하는 클래스의 통신망)를 분할할 수 있다.

테스트를 하려면 실제 제품에 해당하는 의존성 외에 테스트 목적의 의존성들로 구성해서 대체해야 한다.
직접 참조하는 의존성을 테스트 목적의 의존성으로 대체하고, 해당 의존성들이 다시 테스트 목적의 의존성을 참조하는 식으로
의존성 → 의존성 으로 계속 넘어가 결국 테스트 목적의 의존성을 참조하는 식으로 모두 대체하게 되면 결국 이 작업은 "그래프를 다시 만든다"라고 할 수 있는 것!

 

텍스트 대역을 사용하면 객체 그래프를 다시 만들지 않아도 되고, 클래스의 직접적인 의존성을 대체하며 더 나아가 의존성의 의존성을 다룰 필요가 없다.

 

고전적 스타일로 작성된 테스트

public class CustomerTests
{
    [Fact]
    public void Purchase_succeeds_when_enough_inventory()
    {
        // 준비
        var store = new Store();
        store.AddInventory(Product.Shampoo, 10);
        var customer = new Customer();

        // 실행
        bool success = customer.Purchase(store, Product.Shampoo, 5);
        
        // 검증
        Assert.True(success);
        Assert.Equal(5, store.GetInventory(Product.Shampoo)); // 상품 재고 5개 감소
    }

    [Fact]
    public void Purchase_fails_when_not_enough_inventory()
    {
        // 준비
        var store = new Store();
        store.AddInventory(Product.Shampoo, 10);
        var customer = new Customer();

        // 실행
        bool success = customer.Purchase(store, Product.Shampoo, 15);
        
        // 검증
        Assert.False(success);
        Assert.Equal(10, store.GetInventory(Product.Shampoo)); // 상품 재고 수량 변화 없음
    }
}

 

• 준비: 의존성과 테스트 대상 시스템을 모두 준비
• 실행: 검증하고자 하는 동작 수행
• 검증: 검증 단계, 동작이 예상 결과로 이어지는지 확인

 

준비단계에서는 테스트 대상 시스템(SUT: System Under Test)과 협력자를 준비한다.

var store = new Store();
store.AddInventory(Product.Shampoo, 10);
var customer = new Customer();

 

위 경우, Customer-고객이 SUT, Store-상점이 협력자에 해당한다.

테스트 대상 메서드 (MUT: Method Under Test)는 테스트에서 호출한 SUT의 메서드이다.
SUT와 MUT는 동의어로 쓰이기도 하지만, 보통 SUT는 클래스 전체, MUT는 메서드를 가리킨다.

 

여기서 테스트 대상 메서드인 customer.Purchase()는 Store 인스턴스를 필수로 필요로 하고,

검증 단계에서 Purchase()의 결과 중 하나로 상점 제품 수량이 감소할 가능성이 있기에 Store 협력자가 필요한 것이다.

• 여기서 Product.Shampoo, 숫자 5, 15는 상수로 취급한다.

 

여기서는 단위 테스트의 고전 스타일의 예로, 테스트는 협력자(Store)를 대체하는 클래스를 따로 만들어서 사용하지 않고, 운영 인스턴스를 사용하고 있다.

Customer과 Store 모두 효과적으로 검증할 수 있으나, 두 클래스가 서로 격리된 테스트는 아니기에 Customer가 올바르게 작동 하더라도 Customer에 영향을 미치는 Store 내부에 버그가 있으면 단위 테스트에 실패할 수도 있는 것이다.

 

런던 스타일로 작성된 테스트

위와 동일한 예제를 런던 스타일로 작성해보면 어떨까?

동일한 테스트에서 Store 인스턴스는 테스트 대역, "목"으로 교체해보자.

Mock은 테스트 대상 시스템과 협력자 간의 상호 작용을 검사할 수 있는 특별한 테스트 대역이다.

• 테스트 대역과 목은 동의어가 아니다.
• 테스트 대역은 모든 종류의 가짜 의존성을 설명하는 포괄적인 용어이고, 목은 그러한 의존성의 한 종류인 것.

public class CustomerTests
{
    [Fact]
    public void Purchase_succeeds_when_enough_inventory()
    {
        // 준비
        var storeMock = new Mock<IStore>();
        storeMock
            .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
            .Returns(true);
        var customer = new Customer();

        // 실행
        bool success = customer.Purchase(storeMock.Object, Product.Shampoo, 5);

        // 검증
        Assert.True(success);
        storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Once);
    }

    [Fact]
    public void Purchase_fails_when_not_enough_inventory()
    {
        // 준비
        var storeMock = new Mock<IStore>();
        storeMock
            .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
            .Returns(false);
        var customer = new Customer();

        // 실행
        bool success = customer.Purchase(storeMock.Object, Product.Shampoo, 5);

        // 검증
        Assert.False(success);
        storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Never);
    }
}

 

 

준비 단계에서 런던 스타일의 테스트는

var storeMock = new Mock<IStore>();
storeMock
    .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
    .Returns(true);
var customer = new Customer();

 

1. 실제 Store 인스턴스를 사용하지 않고, Mock을 사용해 대체하였다.
2. 샴푸의 재고를 추가하여 Store의 상태를 변화시키는 대신,
   HasEnoughInventory() 메서드 호출에 어떻게 응답하는지 목에 직접 정의하였다.
   → Store의 상태와 상관 없이 테스트가 요구하는 방식으로 요청에 응답하게 하는 것!

< 2번 추가 설명 >

이는 Purchase() 메소드에서 HasEnoughInventory() 메소드를 사용하기 때문인데,
미리 HasEnoughInventory에 (Product.Shampoo, 5) 라는 매개변수를 넣으면 해당 메소드의 로직이나, 오류 여부와 상관 없이 무조건 true를 반환하도록 설정해준 것이다.

public bool Purchase(IStore store, Product product, int quantity)
{
    if (!store.HasEnoughInventory(product, quantity))
    {
        return false;
    }

    store.RemoveInventory(product, quantity);

    return true;
}​

 

 

검증 단계에서 클래식과 런던 스타일은 더 명확한 차이점을 확인할 수 있다.

Assert.True(success);
storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Once);

 

클래식에서는 상점 상태를 검증했다면, 지금은 Customer과 Store간의 상호 작용을 검사한다.

즉, 고객이 상점에서 호출을 올바르게 했는지, 호출 횟수는 정확했는지도 확인할 수 있다.

1. 고객이 상점의 RemoveInventory() 메소드를
2. 한 번 호출했는지 검증할 수 있는 것.

 

구매에 성공했을 때와 실패했을 때를 비교하여 살펴보면 다음과 같이 호출 횟수가 정확했는지 확인하는 코드를 볼 수 있다.

1. 성공했을 때는 RemoveInventory() 메소드를 한 번 (Times.Once) 호출해야 한다.
2. 실패했을 때는 RemoveInventory() 메소드를 호출하면 안된다. (Times.never)

// inventory가 충분하여 구매에 성공했을 때의 검증 과정
Assert.True(success);
storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Once);

// inventory가 부족하여 구매에 실패했을 때의 검증 과정
Assert.False(success);
storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Never);

 

격리 문제에 대한 고전파의 접근

단위테스트는

1. 작은 코드 조각을 검증하고
2. 빠르게 수행하고
3. 격리된 방식으로 처리하는 자동화된 테스트이다.

라고 정의했다. 

 

만약, 런던 스타일처럼 테스트 대역으로 대상 코드 조각을 분리해서 격리해야 한다면, 이는 1번의 무엇이 "작은 코드 조각"인가에 대한 견해에도 영향을 미칠 수 있다.

여기서 작은 코드 조각은 얼마나 작아야 할까?

 

런던파에서는 당연히 모든 클래스를 격리해야 하기에, 조각은 당연히 단일 클래스이거나 해당 클래스 내의 메서드이어야 한다. 

 

그렇다면 고전파에서는 어떨까?

고전적인 방법에서는 꼭 코드를 격리하는 방식으로 테스트해야 하는 것은 아니다. 하지만 테스트의 순서에 상관없이 여러 클래스를 한 번에 테스트해도 괜찮아야 한다.

• 테스트가 서로 소통하고, 실행 컨텍스트에 영향을 줄 수 있음.
  DB, 파일 시스템 등 프로세스 외부 의존성이 이러한 "공유 상태"의 대표적인 예임.

격리 문제에 대한 이런 상반된 견해는 목과 기타 테스트 대역의 사용에 견해를 수반함.

테스트 대역을 사용할 수 있지만, 보통 테스트 간에 공유 상태를 일으키는 의존성에 대해서만 사용함.

 

 

 

단위테스트를 서로 격리하는 것은 테스트 대상 클래스에서 "공유 의존성"만 격리하는 것을 의미한다.

• 비공개 의존성은 그대로 둘 수 있음.

 

여기서 공유 의존성은 테스트 대상 클래스 간이 아니라 단위 테스트 간 공유한다.

 

singleton 의존성 : 각 테스트에서 새 인스턴스를 만들 수 있기만 하면 공유되지 않음.

• ※ 싱글톤: 클래스의 인스턴스를 하나만 생성하여 메모리 사용을 최적화하고, 전역적으로 접근할 수 있도록 하는 것.

• 제품 코드에서는 싱글턴 인스턴스가 단 하나만 있을 것.
  하지만 테스트에서는 이 패턴을 따르지도 않고, 재사용하지도 않음.
  → 이러한 의존성은 "비공개" 이다!

ex)

설정 configuration 클래스는 일반적으로 한 개이며, 모든 제품 코드에서 이 인스턴스를 재사용함.

그러나 다른 모든 의존성이 SUT(테스트 대상 시스템)에 주입되면 각 테스트에서 새 인스턴스를 만들 수 있음.

• 테스트 스위트 전체에서 단일 인스턴스를 유지할 필요는 없음
• 그러나 새 파일 시스템이나 DB를 만들 수는 없으며, 테스트 간에 공유되거나 테스트 대역으로 대체되어야 함.

 

공유 의존성을 대체하는 또 다른 이유는 테스트 실행 속도를 높이기 위해서임.

프로세스 외부에 있기 때문에 비공개 의존성보다 호출에 더 오랜 시간이 걸리기 때문.

 

참고) 공유 의존성, 비공개 의존성, 프로세스 외부 의존성

공유 의존성

• 테스트 간에 공유되고 서로의 결과에 영향을 미칠 수 있는 수단을 제공하는 의존성
• ex) 정적 가변 필드, 데이터베이스

비공개 의존성

• 공유하지 않는 의존성

프로세스 외부 의존성

• 애플리케이션 실행 프로세스 외부에서 실행되는 의존성. 아직 메모리에 없는 데이터에 대한 프록시(proxy)
• 대부분 "공유 의존성"에 해당함. (전부는 아님)
• 예시
  • 데이터베이스 = 프로세스 외부 + 공유 의존성
  • 테스트 전 도커 컨테이너로 데이터베이스 실행 = 프로세스 외부 + 공유하지 않는 의존성
    (테스트가 더 이상 동일한 인스턴스로 작동하지 않기 때문.)

 

단위 테스트의 런던파와 고전파

런던파와 고전파로 나누어진 원인은 "격리 특성"

• 런던파: 테스트 대상 시스템에서 협력자를 모두 격리한다.
• 고전파: 단위 테스트끼리 격리한다.

 

격리 요구 사항 / 테스트 대상 코드 조각(단위)의 구성 요소 / 의존성 처리에 대한 의견 차이가 존재한다.

	격리 주체	단위의 크기	테스트 대역 사용 대상
런던파	단위	단일 클래스	불변 의존성 외 모든 의존성
고전파	단위 테스트	단일 클래스 또는 클래스 세트	공유 의존성

 

고전파와 런던파가 의존성을 다루는 방법

런던파에서는 "불변 객체"는 교체하지 않고 그대로 사용할 수 있다.

 

런던 스타일로 리팩토링된 테스트 코드를 살펴보면,

Product.Shampoo 에 대한 인스턴스는 목으로 교체하지 않고, 실제 객체를 사용하고 있다. 

→ 따라서 가변적인 Store만 교체한 것!

• Store만 변하는 내부 상태를 포함하고 있음.
• Product는 (enum) 열거형으로 불변임.

(Product.Shampoo, 5) 에서 "5"라는 숫자에 테스트 대역을 사용하지 않는 것도 비슷한 맥락임.

[Fact]
public void Purchase_fails_when_not_enough_inventory()
{
    // 준비
    var storeMock = new Mock<IStore>();
    storeMock
        .Setup(x => x.HasEnoughInventory(Product.Shampoo, 5))
        .Returns(false);
    var customer = new Customer();

    // 실행
    bool success = customer.Purchase(storeMock.Object, Product.Shampoo, 5);

    // 검증
    Assert.False(success);
    storeMock.Verify(x => x.RemoveInventory(Product.Shampoo, 5), Times.Never);
}

 

이러한 불변 객체를 값 객체 또는 값이라고 함.

• 각각의 정체성이 없고 내용에 의해서만 식별됨.
• 두 객체가 "동일한 내용"을 갖고 있다면, 어떤 객체를 사용하든 상관이 없음.
  → 같은 내용이라면 서로 바꿔 사용할 수도 있는 것!

 

 

		런던파	고전파
의존성	공유 의존성 (협력자)	교체 대상	교체 대상
	비공개 의존성
비공개 의존성	변경 가능한 의존성 (협력자)	교체 대상
	값 객체

 

협력자와 의존성

협력자: 공유하거나 변경 가능한 의존성

• 공유 의존성 ex) 데이터베이스
• 변경 가능한 의존성 ex) Store - 시간에 따라 상태가 변경됨.
  • 여기서 Product나 숫자 5는 의존성이지만 협력자가 아님. 그냥 값 객체인것.

customer.Purchase(store, Product.shampoo, 5)

 

공유 의존성과 외부 의존성

모든 프로세스 외부 의존성이 "공유 의존성"의 범주에 속하는 것은 아니다.

 

프로세스 외부 의존성을 공유하려면 단위 테스트가 서로 통신할 수 있는 수단이 있어야 함.

 

의존성 내부 상태를 수정하면 통신이 이뤄지는데,

프로세스 외부의 불변 의존성은 그런 수단을 제공하지 않음.

• 테스트는 내부의 어떤 것도 수정할 수 없기에, 서로 실행 컨텍스트에 영향을 주지 않는 것.

 

 

공유, 프로세스 외부 X | 싱글턴 (모든 테스트에서 재사용하는 인스턴스), 클래스의 정적 필드

공유, 프로세스 외부 | 데이터베이스

공유X, 프로세스 위부 | 읽기 전용 API

• 수정할 수 없으며, 이로 인해 서로의 실행 흐름에 영향을 줄 수 없기 때문
• 테스트가 반환하는 데이터에 영향을 미칠 수 없음.
• 보통 프로세스 외부이며 공유되지 않는 의존성은 충분히 빠르고 연결이 안정적이지 않는 한, 보통 교체된다.

 

물론 실제 프로젝트에서는 프로세스 외부가 아닌 공유 의존성은 거의 없다.

(→ 정리할 때도 공유 의존성과 프로세스 외부 의존성이라는 용어는 서로 바꿀 수 있게 사용할 예정)

 

고전파와 런던파의 비교

필자는 고전파를 더 선호함. 목을 사용하는 테스트는 불안정한 경향이 있기 때문.

 

런던파의 접근 방식의 이점

• 입자성 granularity이 좋음. 테스트가 세밀해서 한 번에 한 클래스만 확인함.
• 서로 연결된 클래스의 그래프가 커져도 테스트하기에 쉬움. 모든 협력자가 테스트 대역으로 대체되기 때문.
• 테스트가 실패하면 어떤 기능이 실패했는지 확실히 알 수 있음. 애초에 모든 의존성을 모두 제거했기 때문.

한 번에 한 클래스만 테스트하기

런던파는 클래스를 단위로 간주한다.

TIP
테스트는 코드의 "단위"를 검증해서는 안 된다.
오히려 동작의 단위, 즉 "문제 영역"에 의미가 있는 것. 이상적으로는 비즈니스 담당자가 유용하다고 인식할 수 있는 것을 검증해야 한다.
따라서 동작 단위를 구현하는 데 클래스가 얼마나 필요한지는 상관이 없다.
단위는 여러 클래스에 걸쳐 있거나, 한 클래스에만 있을 수도 있고, 아주 작은 메서드가 될 수도 있다.

 

따라서 "좋은 코드 입자성"을 목표로 하는 것은 도움이 되지 않는다.

"단일 동작 단위"를 검증하는 것이 좋은 테스트지, 이보다 적은 것을 목표로 삼는다면 단위 테스트를 훼손하는 것이다.

이 테스트가 "무엇을 검증하는지" 정확히 이해할 수 있어야 한다

• 해결하는 데 도움이 되는 문제에 대한 이야기를 들려주어야 하며,
• 프로그래머가 아닌 일반 사람들에게 응집도가 높고 의미가 있어야 한다.

상호 연결된 클래스의 큰 그래프를 단위 테스트하기

목을 사용하면 의존성 그래프가 복잡하게 있을 때 쉬운 테스트가 가능함.

클래스의 직접적인 의존성을 대체해 그래프를 나눌 수 있으며, 단위 테스트에서 준비해야 할 작업량을 크게 줄이기 때문!

 

하지만 이는 잘못된 문제에 초점을 맞추고 있음.

상호 연결된 클래스의 크고 복잡한 그래프를 테스트할 방법을 찾는 대신, 이러한 클래스 그래프를 갖지 않는 데에 먼저 집중해야 함.

클래스 그래프가 커진 것은 코드 설계 문제의 결과임

 

버그 위치 정확히 찾아내기

고전 스타일 테스트에서는 오작동하는 클래스의 참조하는 클라이언트를 대상으로하는 테스트도 실패할 수 있음.

즉, 하나의 버그가 전체 시스템에 걸쳐 테스트 실패를 야기할 수 있는 것.

 

결국 이는 문제의 원인을 찾기가 더 어려워지고, 디버깅에 더 많은 시간을 요구할 수 있다.

 

우려할 만하지만, 큰 문제는 아니다. 테스트를 정기적으로 실행시켜 버그의 원인을 찾는다면,

마지막으로 한 수정이 무엇인지 알기 때문에 버그의 원인을 찾는 것은 크게 어렵지 않다.

 

또한, 테스트 스위트 전체에 걸쳐 계단식으로 실패하는 데 가치가 있다.

버그가 테스트 하나뿐만 아니라, 많은 테스트에서 결함으로 이어진다면? 방금 고장 낸 코드 조각이 큰 가치가 있다는 것을 보여주는 것이다.

= 즉, 전체 시스템이 그것에 의존한다는 것이다.

이는 코드 작업 시 명심해야 할 유용한 정보이다.

 

고전파와 런던파 사이의 다른 차이점

아직 고전파와 런던파 사이에 남아있는 두 가지 차이점은 다음과 같다.

• 테스트 주도 개발 (TDD: Test Driven Development) 을 통한 시스템 설계 방식
• 과도한 명세 문제

 

런던 스타일의 단위 테스트

• 하향식 TDD : 전체 시스템에 대한 기대치를 설정하는 상위 레벨 테스트부터 시작함.
• 목을 사용해 예상 결과를 달성하고자 시스템이 통신해야 하는 협력자를 지정함
• 모든 클래스를 구현할 때까지 클래스 그래프를 다져나감.
• 테스트할 때 SUT의 모든 협력자를 차단하여 해당 협력자의 구현을 나중으로 미룰 수 있음.

 

고전 스타일의 단위 테스트

• 상향식 TDD : 도메인 모델을 시작으로 최종 사용자가 소프트웨어를 사용할 수 있을 때까지 계층을 그 위에 더 둠.

 

이 중에서도 가장 주요한 차이점은 "과도한 명세 문제"

런던 스타일은 고전 스타일보다 테스트가 SUT의 구현 세부 사항에 더 자주 결합되는 편이다.

 

두 분파의 통합 테스트

런던파 : 실제 협력자 객체를 사용하는 모든 테스트를 통합 테스트라고 간주

• 따라서 고전스타일로 작성된 대부분의 테스트는 런던파에서는 통합 테스트로 간주됨.

 

고전파의 관점에서 단위테스트는

• 단일 동작 단위를 검증하고
• 빠르게 수행하고
• 다른 테스트와 별도로 처리한다.

통합테스트는 이러한 기준 중 하나를 충족하지 않는 테스트임.

예를 들어 공유 의존성에 접근하는 테스트는 다른 테스트와 분리하여 실행할 수 없음.

• 어떤 테스트에서 DB 상태 변경이 생기면 다른 테스트와 병렬로 실행시 다른 모든 테스트의 결과가 변경될 것임.

 

프로세스 외부 의존성에 접근하면 테스트가 느려짐.

 

이론적으로 메모리 내 객체로만 작동하는 테스트를 작성할 수도 있지만, 쉽지는 않음.

• 동일한 메모리 공간에 있는 객체 간 통신은 별도 프로세스 간 통신보다 훨씬 저렴함.
• 테스트가 메모리 내 객체 수백 개와 함께 작동하더라도, 데이터베이스 호출보다 빠르게 실행될 것임.

 

둘 이상의 동작 단위를 검증할 때의 테스트는 통합 테스트임.

• 비슷한 단계를 따르지만 다른 동작 단위를 검증하는 "느린" 테스트가 두 개 있을 때, 하나로 합치는 것이 타당할 수 있음.
• 다른 팀이 개발한 모듈이 둘 이상 있을 때 통합 테스트로 어떻게 작동하는지 검증할 수 있음.

 

엔드 투 엔드 테스트

통합테스트: 공유 의존성, 프로세스 외부 의존성 뿐 아니라 조직 내 다른 팀이 개발한 코드 등과 통합해 작동하는지도 검증하는 테스트

 

엔드 투 엔드 테스트는 이 통합 테스트의 일부임.

• 코드가 프로세스 외부 조속성과 함께 어떻게 작동하는지 검증
• 통합테스트보다 일반적으로 의존성을 더 많이 포함함.

 

통합 테스트는 프로세스 외부 의존성을 한두 개만 갖고 작동하는 반면, 

엔드 투 엔드 테스트는 프로세스 외부 의존성을 전부 또는 대다수를 갖고 작동함.

• UI / GUI / 기능 테스트 라고도 불림

 

애플리케이션이 데이터베이스 / 파일 시스템 / 결제 게이트웨이 라는 세 가지 프로세스 외부 의존성으로 작동한다고 가정해보자.

• 일반적인 통합 테스트는 DB + 파일 시스템만 포함하고 결제 게이트웨이는 테스트 대역으로 대체함.
• 결제 게이트웨이의 제어 권한은 DB / 파일 시스템에 비해 완전히 제어할 수 없기 때문.

 

즉 보통의 통합 테스트는 자동으로 설정하기 쉬운 의존성만 확인하지만,

엔드 투 엔드 테스트는 프로젝트 외부 의존성을 거의 모두 확인함.

 

엔드 투 엔드 테스트를 하더라도 모든 프로세스 외부 의존성을 처리하지 못할 수도 있음.

따라서 여전히 테스트 대역을 사용할 필요가 있고, 통합 테스트와 엔드 투 엔드 테스트 사이에 뚜렷한 경계가 없다는 사실도 명심해야 함.