단위와 통합 간의 격차 테스트 : 소규모, 컴포넌트, 단위 통합 테스트의 통합

지난 몇 주 동안 저는 테스트 방법론의 차이를 메우는 방법을 연구하고있었습니다. 간략하게 말하면 단위 테스트는 너무 작고 기존 통합 테스트는 너무 큽니다.

빈번한 시나리오가 등장 A하고 B모두 사용하는 구성 요소를 C. 그러나 A에 B대해 약간 다른 요구 사항이 있으며에 대해 약간 다른 가정을 C합니다. 내가 A어떻게 그리고 어디에서 내 가정을 테스트 C합니까?

분명히 모의 A가정을 사용한 단위 테스트 는 격리 C테스트 A에 적합하지만 가정 자체를 테스트하지는 않습니다.

또 다른 가능성은에 대한 단위 테스트를 추가하는 것입니다 C. 그러나 이것은 A개발 중일 때 C진화하는 가정에서 테스트를 변경하는 A것이 지나치게 어색 하기 때문에 이상적이지 않습니다 . 실제로 A개발자는 단위 테스트 C(예 : 외부 라이브러리)에 대한 적절한 액세스 권한이 없을 수도 있습니다 .

좀 더 구체적인 예제를 사용하여이를 구성하려면 다음을 수행하십시오. 이것이 노드 응용 프로그램이라고 가정하십시오. A과 B에 따라 C(다른 것들 사이) 파일을 읽고에 전달 된 객체의 파일 내용을 저장합니다 C. 처음에 C처리하는 모든 파일 은 작고 상당한 차단없이 동 기적으로 읽을 수 있습니다. 그러나 개발자는 B파일이 C커지고 비동기 읽기 로 전환해야한다는 것을 알고 있습니다. 에 산발적 인 동기화 버그가 발생하여 파일을 동 기적으로 읽는 A다고 가정 C합니다.

이는 전체 통합 테스트에서 추적하기 어려운 버그 유형이며 통합 테스트에서 전혀 발견되지 않을 수 있습니다. 또한 가정이 모의 A되기 때문에 단위 테스트 에서도 포착되지 않습니다 A. 그러나 쉽게 단지 행사는 "미니"통합 테스트에 의해 잡힐 수 A및 C.

이 유형의 테스트에 대한 몇 가지 참조 만 찾았습니다. 소형의 통합 , 구성 요소 통합 테스트 , 단위 통합 테스트. 또한 공식적인 TDD 단위 테스트보다는 BDD 테스트 방향 과 관련이 있습니다 .

이 테스트 간격을 어떻게 채우나요? 구체적으로, 이러한 테스트를 어디에 두어야합니까? 어떻게의 입력 조롱 않습니다 A와 C"미니"통합 시험을? 그리고 이러한 테스트와 단위 테스트 사이의 테스트 문제를 분리하기 위해 얼마나 많은 노력을 기울여야합니까? 아니면 테스트 간격을 채우는 더 좋은 방법이 있습니까?

구성 요소에 근본적인 문제가있는 것 같습니다.

C는 C가해야 할 일을 수행해야하며이를 수행하기 위해 테스트, 문서화 및 설계되어야합니다. C가 "B가 원하는 일을하도록"설계된 상황에서는 A가 도착하고 C가 약간 다른 일을 할 때 매우 분명한 모순적인 관계가 있습니다.

당신이하지 말아야 할 것은 A와 관련하여 C를 단위 테스트하고, 특히 C와 관련하여 A를 테스트하지 않는 것입니다 .A를 독립적으로 테스트하고 모의 C의 결과를 A에 제공합니다. C는 동일한 결과를 제공하지 않으며, 큰 통합 테스트를 수행 할 때 C에 버그 나 디자인 결함이 있습니다. 단위 테스트는 항상 이런 방식으로 이루어졌습니다. 다른 단위를 동시에 테스트하여 한 단위를 테스트 할 수는 없습니다. 단위 테스트는 그렇게하기 위해 설계된 것이 아닙니다.

통합 테스트는 "전체 프로그램"일 필요는 없지만 자주 그런 식으로 설정됩니다. 그들은 프로그램의 나머지 부분을 실행하지 않고 A와 C를 함께 실행하는 테스트 장비가 될 수 있습니다. 이 시점에서 이러한 구성 요소가 수행하는 작업과 나머지 프로그램과의 상호 작용 방식에 따라 더 이상 조언을 할 수 없지만 일반적으로 두 구성 요소에 대한 테스트 범위를 제공하는 테스트 장비를 작성할 수 있습니다. 그렇게하는 데 노력을 기울일 가치가 있는지 또는 전체 프로그램을 하나로 통합 테스트하는 것이 더 효율적인지 여부 (통합 테스트의 하위 집합을 실행하더라도)는 응답 할 수있는 것입니다. 대부분의 통합 테스트는 여러 섹션으로 구성되어 있으므로이 두 구성 요소와 관련된 항목 만 실행할 수 있어야합니다.