통합과 단위 테스트의 차이점은 무엇입니까?


307

단위 테스트 및 통합 테스트의 소위 교과서 정의를 알고 있습니다. 궁금한 점은 단위 테스트를 쓸 시간이되었을 때입니다. 가능한 많은 클래스 세트를 다루기 위해 작성합니다.

예를 들어 Word수업 이 있으면 수업에 대한 단위 테스트를 작성합니다 Word. 그 후, 나는 나의 쓰기 시작 Sentence클래스를, 그리고이 상호 작용해야하는 경우 Word클래스, 나는 종종 내 장치들이 모두 테스트하도록 테스트 기록합니다 SentenceWord곳에 그들이 상호 작용 적어도 곳에서 ....

이 테스트는 이제이 두 클래스의 통합을 테스트하기 때문에 통합 테스트가 되었습니까? 아니면 두 클래스에 걸친 단위 테스트입니까?

일반적으로이 불확실한 선 때문에 실제로 통합 테스트를 작성하는 경우는 거의 없습니다. 또는 완성 된 제품을 사용하여 모든 조각이 수동이고 범위를 넘어서 거의 반복되지 않더라도 실제 통합 테스트가 제대로 작동하는지 확인합니다. 각 개별 기능의

통합 테스트를 오해하고 있습니까? 아니면 통합 테스트와 단위 테스트 사이에 거의 차이가 있습니까?

답변:


300

나에게 중요한 차이점은 통합 테스트 에서 기능이 작동하거나 깨 졌는지 여부를 밝혀내는 것입니다. 실제와 가까운 시나리오에서 코드에 스트레스를주기 때문입니다. 하나 이상의 소프트웨어 메소드 또는 기능을 호출하고 예상대로 작동하는지 테스트합니다.

반대로 단일 방법을 테스트 하는 단위 테스트 는 모든 종속성을 명시 적으로 조롱하기 때문에 나머지 소프트웨어가 올바르게 작동한다고 가정합니다 (종종 잘못된 가정).

따라서 일부 기능을 구현하는 방법에 대한 단위 테스트가 녹색 인 경우 기능이 작동하고있는 것은 아닙니다 .

다음과 같은 방법이 있다고 가정 해보십시오.

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  Log.TrackTheFactYouDidYourJob();
  return someResults;
}

DoSomething고객에게 매우 중요합니다. 기능 만 중요합니다. 그렇기 때문에 일반적으로 Cucumber 사양을 작성 하여 기능이 작동 하는지 여부확인 하고 전달 하려고합니다 .

Feature: To be able to do something
  In order to do something
  As someone
  I want the system to do this thing

Scenario: A sample one
  Given this situation
  When I do something
  Then what I get is what I was expecting for

의심 할 여지없이 : 테스트에 통과하면 작업 기능을 제공한다고 주장 할 수 있습니다. 이것이 바로 비즈니스 가치 라고 부릅니다 .

단위 테스트를 작성 DoSomething하려면 나머지 클래스와 메소드가 작동하는 것 (즉, 메소드가 사용하는 모든 종속성이 올바르게 작동 함)을 척하고 (모의를 사용하여) 메소드가 작동하고 있다고 주장해야합니다.

실제로 다음과 같은 작업을 수행합니다.

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
  return someResults;
}

Dependency Injection, Factory Method 또는 Mock Framework를 사용하거나 테스트중인 클래스를 확장 하여이 작업을 수행 할 수 있습니다.

에 버그가 있다고 가정합니다 Log.DoSomething(). 운 좋게도 Gherkin 사양에서이를 찾아 내고 종단 간 테스트에 실패합니다.

기능이 작동하지 않습니다. 기능이 작동 Log하지 않기 때문 [Do your job with someInput]이 아닙니다. 그리고 [Do your job with someInput]그 방법에 대한 책임은 전적으로 귀하에게 있습니다.

또한 Log100 개의 다른 기능, 100 개의 다른 클래스의 100 개의 다른 메소드에서 사용 된다고 가정하십시오 .

그러나 100 가지 기능이 실패합니다. 그러나 다행스럽게도 100 개의 엔드 투 엔드 테스트가 실패하고 문제가 드러났습니다. 그리고 그렇습니다 : 그들은 진실을 말하고 있습니다.

매우 유용한 정보입니다. 깨진 제품이 있다는 것을 알고 있습니다. 또한 매우 혼란스러운 정보입니다. 문제가 어디에 있는지 전혀 알려주지 않습니다. 근본 원인이 아니라 증상을 알려줍니다.

그러나 DoSomething단위 테스트는 Log절대로 깨지지 않는 가짜를 사용하기 때문에 녹색 입니다. 그리고 그렇습니다 : 그것은 분명히 거짓말 입니다. 고장난 기능이 작동 중임을 알리고 있습니다. 어떻게 유용 할 수 있습니까?

( DoSomething()의 단위 테스트에 실패하면 [Do your job with someInput]몇 가지 버그가 있습니다.)

이것이 클래스가 깨진 시스템이라고 가정하십시오. 클래스가 깨진 시스템

하나의 버그로 여러 기능이 중단되고 여러 통합 테스트가 실패합니다.

단일 버그로 인해 여러 기능이 중단되고 여러 통합 테스트가 실패합니다

반면에 동일한 버그는 단 하나의 단위 테스트 만 중단합니다.

동일한 버그로 단 하나의 단위 테스트 만 중단됩니다.

이제 두 시나리오를 비교하십시오.

동일한 버그로 단 하나의 단위 테스트 만 중단됩니다.

  • 깨진 Log부분을 사용하는 모든 기능 은 빨간색
  • 모든 단위 테스트는 녹색이고 단위 테스트 Log는 빨간색입니다

실제로는 기능을 사용하지 않는 모든 모듈에 대한 단위 테스트는 녹색입니다. 모의를 사용하면 종속성이 제거 되었기 때문입니다. 다시 말해, 그들은 이상적인 가상의 세계에서 실행됩니다. 그리고 이것이 버그를 격리하고 찾는 유일한 방법입니다. 단위 테스트는 조롱을 의미합니다. 조롱하지 않으면 단위 테스트가 아닙니다.

차이점

통합 테스트는 작동하지 않는 것을 알려줍니다 . 그러나 문제의 위치추측하는 데 아무런 소용이 없습니다 .

단위 테스트는 버그의 정확한 위치 를 알려주는 유일한 테스트입니다 . 이 정보를 얻으려면 다른 모든 종속 항목이 올바르게 작동하는 모의 환경에서 메소드를 실행해야합니다.

그렇기 때문에 당신의 문장이 "아니면 2 개의 수업에 걸친 단위 테스트 일뿐"이라는 말이 어떻게 바뀌 었는지 생각합니다. 단위 테스트는 2 개의 클래스에 걸쳐서는 ​​안됩니다.

이 답변은 기본적으로 여기에 쓴 내용에 대한 요약입니다. 단위 테스트는 거짓말 입니다.


6
정말 좋은 답변입니다! 그러나 나는 조롱이 단위 테스트만을위한 것이 아니라고 덧붙이고 싶습니다. 또한 많은 통합 테스트 사례에서 매우 유용 할 수 있습니다.
n.Stenvang

1
좋은 대답입니다! 나는 단지 두 가지 요점에 동의하지 않는다. 1) 통합 테스트는 "문제가 어디에 있는지 추측하는 데 아무 소용이 없다"; 그리고 2) "단위 테스트는 절대 2 클래스를 거치지 않아야한다". 나는 많은 통합 테스트를 만들었고, 실패했을 때 전체 스택 추적 또는 단일 실패한 단언 (이 경우 소스를 찾기가 더 어려울 수 있음)을 얻는 경우 일반적으로 문제의 소스를 정확히 찾아내는 것이 어렵지 않습니다. 통합 테스트는 디버깅을 위해 포함 된 컨텍스트를 제공하기 때문에 그리 많지 않습니다. (계속)
Rogério

5
단위 테스트 별도의 단위 테스트를 가져야하는 공개 클래스가 아닌 경우 여러 클래스 연습 할 수 있습니다 . 공개 테스트 클래스가 공개 클래스를 지원하기 위해 존재하는 다른 비공개 도우미 클래스를 사용하는 경우가 있습니다. 이 경우, "단위"는 둘 이상의 클래스를 포함한다. 또 다른 경우는 대부분의 클래스가 조롱 또는 격리되지 않는 타사 클래스 (문자열 / 문자열 클래스, 컬렉션 클래스 등)를 사용한다는 것입니다. 테스트 범위를 벗어나는 안정적이고 신뢰할 수있는 종속성으로 간주합니다.
Rogério

2
통합 테스트를 사용하면 근본 문제를 찾기가 약간 어렵지만 여전히 디버깅하여 근본 문제를 찾을 수 있습니다. 단위 테스트가 자주 실패한다고 가정하면 통합 테스트 만 있으면 버그를 수정하는 데 약간의 시간이 더 걸리지 않지만 테스트 구성 요소 통합의 부가 가치를 얻음으로써 작성 시간을 절약 할 수 있습니다 단위 테스트. 나는이 주장 (내 상사로부터 온)이 잘못되었다고 생각하지만, 어떻게 생각을 설득 할 수 있을지 모르겠다.
BornToCode

1
이 답변의 추론에 따르면, 단위 테스트 작성을 건너 뛰고 실패 할 때 통합 테스트 실패 소스를 찾아서 시간을 절약하는 것이 더 효과적이라고 주장 할 수 있습니다.

62

단위 테스트를 작성할 때 테스트중인 코드의 범위를 현재 모의 종속성으로 작성하는 클래스로 제한합니다. Sentence 클래스를 작성 중이고 Sentence가 Word에 종속 된 경우 모의 Word를 사용합니다. Word를 조롱함으로써 해당 인터페이스에만 집중하고 Word 인터페이스와 상호 작용할 때 내 Sentence 클래스의 다양한 동작을 테스트 할 수 있습니다. 이 방법으로 나는 문장의 행동과 구현만을 테스트하고 동시에 Word의 구현을 테스트하지는 않습니다.

Word의 인터페이스를 기반으로 Word와 상호 작용할 때 문장이 올바르게 작동하는지 확인하기 위해 단위 테스트를 작성한 후에는 상호 작용에 대한 내 가정이 올바른지 확인하기 위해 통합 테스트를 작성합니다. 이를 위해 실제 객체를 제공하고 문장과 단어를 모두 사용하는 기능을 수행하는 테스트를 작성합니다.


43

내 10 비트 : D

나는 항상 단위 테스트개별 구성 요소 의 테스트 라고 들었 습니다. 이제는 대부분의 구성 요소가 더 작은 부품으로 만들어지기 때문에 많은 수준을 유지하는 경향이 있습니다. 나를 위해, 단위 는 시스템의 기능적인 부분입니다. 따라서 가치있는 무언가를 제공해야합니다 (즉, 문자열 구문 분석 방법이 아니라 HtmlSanitizer ).

통합 테스트 는 다음 단계로, 하나 이상의 구성 요소를 가져 와서 제대로 작동하는지 확인합니다. 그런 다음 구성 요소가 개별적으로 작동 하는 방식대해 걱정할 필요가 있지만 HtmlEditControl에 html을 입력 하면 어떻게 든 마법의 유효 여부를 마법으로 알고 있습니다.

그것의 진짜 움직일 수있는 선 .. 차라리 코드가 완전히 멈추게하는 것에 더 집중하고 싶다 ^ _ ^


23

단위 테스트는 모의를 사용합니다.

당신이 말하는 것은 실제로 시스템의 전체 통합을 테스트하는 통합 테스트입니다. 그러나 단위 테스트를 수행 할 때는 실제로 각 단위를 개별적으로 테스트해야합니다. 다른 모든 것은 조롱해야합니다. 그래서 당신의 경우 Sentence는 사용하는 경우 클래스, Word클래스를 다음 Word클래스는 조롱한다. 이런 식으로 Sentence수업 기능 만 테스트합니다 .


나는 이것이 오래된 게시물이라는 것을 알고 있지만 방금 건너 왔습니다. Sentence 클래스와 상호 작용하는 Font라는 세 번째 클래스가 있고 Word와 Sentence 클래스 사이의 기능을 테스트하려는 경우 Font 클래스를 조롱해야했지만 이것이 단위 테스트가되지는 않습니다. 그래서 내가 말하는 것은 모의를 사용한다고해서 반드시 단위 테스트가 될 필요는 없으며 모의는 통합 테스트에도 사용될 수 있다는 것입니다.
n.Stenvang

2
물론 모의는 통합 테스트에서 사용될 수 있지만, 단위 테스트가 실제로 는 장치 외부의 모든 것을 시뮬레이션 해야합니다 . 통합 테스트에서 모의를 사용하는 경우 부분 통합 테스트 일 가능성이 높습니다 (해당 용어가있는 경우). 물론 하향식 또는 상향식의 부분 통합 테스트가 있습니다. 후자는 일반적으로 전자는 모의를 요구하지 않습니다.
Robert Koritnik

17

통합 테스트에 대해 생각하기 시작하면 논리적 계층이 아닌 물리적 계층 간의 교차점에 대해 더 많이 이야기하고 있다고 생각합니다.

예를 들어, 테스트 자체가 컨텐츠 생성과 관련이있는 경우 단위 테스트입니다. 테스트가 디스크에 쓰는 것 자체와 관련이있는 경우 여전히 단위 테스트이지만 파일의 I / O와 컨텐츠를 모두 테스트하면, 그런 다음 자신에게 통합 테스트가 있습니다. 서비스 내에서 함수의 출력을 테스트 할 때는 단위 테스트이지만, 일단 서비스를 호출하고 함수 결과가 동일한 지 확인하면 통합 테스트입니다.

기술적으로 당신은 단 하나의 클래스를 단위 테스트 할 수 없습니다. 수업이 다른 여러 수업으로 구성되어 있다면 어떻습니까? 이것이 자동으로 통합 테스트가됩니까? 나는 그렇게 생각하지 않습니다.


8
"어쨌든 한 클래스 만 단위 테스트 할 수는 없습니다. 클래스가 다른 클래스로 구성되어 있다면 어떨까요?" 글쎄, "엄격한"단위 테스트는 모든 의존성을 조롱 / 스텁 할 뿐이다. 그러나 이것이 항상 실용적인지 여부는 논쟁의 여지가 있습니다 ...
sleske

2
사실 지루한 일입니다. 중요한 부분은 종속성을 최소한으로 유지할 수 있다는 것입니다.
Jon Limjap

-1, 단위 테스트는 단일 기능을 테스트하지 않고 단일 소프트웨어 기능 또는 클래스, 즉 소프트웨어의 논리적 단위를 테스트합니다.
CharlesB

12

단일 책임 디자인, 흑백을 사용합니다. 하나 이상의 책임, 통합 테스트.

오리 테스트 (외모, cks, 울음, 오리)에 의해 하나 이상의 새로운 물체가있는 단위 테스트입니다.

mvc에 들어가서 테스트하면 컨트롤러에 모델 단위와 뷰 단위가 모두 포함되므로 컨트롤러 테스트는 항상 통합됩니다. 해당 모델의 로직을 테스트하기 위해 단위 테스트를 호출합니다.


10

테스트의 본질

모듈 X 의 단위 테스트 는 모듈 X에서만 문제를 예상하고 확인하는 테스트입니다.

많은 모듈 의 통합 테스트 는 모듈 간의 협력으로 발생하는 문제를 예상 하여 단위 테스트만으로는 이러한 문제를 찾기가 어렵습니다.

다음과 같은 용어로 테스트의 성격을 생각하십시오.

  • 위험 감소 : 이것이 바로 테스트입니다. 단위 테스트와 통합 테스트조합 만으로 전체 위험을 줄일 수 있습니다. 한편 단위 테스트는 본질적으로 모듈 간의 적절한 상호 작용을 테스트 할 수 없으며 통합 테스트는 사소한 모듈의 기능 만 수행 할 수 있기 때문입니다. 작은 정도로.
  • 테스트 작성 노력 : 통합 테스트는 스텁 / 가짜 / 모의를 작성할 필요가 없기 때문에 노력을 절약 할 수 있습니다. 그러나 스텁 / 가짜 / 모의를 구현 (및 유지 관리) 할 때 단위 테스트도 노력을 아끼지 않고 테스트 설정을 구성하는 것보다 쉽습니다.
  • 테스트 실행 지연 : 무거운 작업 (예 : DB 또는 원격 서버와 같은 외부 시스템에 대한 액세스)과 관련된 통합 테스트는 느립니다. 즉, 단위 테스트를 훨씬 더 자주 실행할 수 있기 때문에 어떤 변화가있을 경우 디버깅 노력이 줄어 듭니다. 테스트 중심 개발 (TDD)을 사용하는 경우 특히 중요합니다.
  • 디버깅 노력 : 통합 테스트가 실패하지만 단위 테스트가 수행되지 않으면 문제 포함될 있는 코드가 너무 많기 때문에 이는 매우 불편할 있습니다. 이전에 몇 줄만 변경 한 경우 큰 문제는 아니지만 통합 테스트가 느리게 실행되면 짧은 간격으로 실행 하지 않았을 수 있습니다.

통합 테스트는 여전히 일부 종속 항목을 스텁 / 가짜 / 모의 할 수 있습니다 . 이것은 단위 테스트와 시스템 테스트 (가장 포괄적 인 통합 테스트, 모든 시스템 테스트) 사이에 충분한 중간 근거를 제공합니다.

두 가지를 모두 사용하는 실용적인 접근 방식

실용적인 접근 방식은 다음과 같습니다. 합리적으로 가능한 한 통합 테스트에 유연하게 의존하고 너무 위험하거나 불편한 단위 테스트를 사용하십시오. 이러한 사고 방식은 단위 테스트와 통합 테스트의 일부 독단적 차별보다 더 유용 할 수 있습니다.


10

단위 테스트에서는 절연 된 모든 부품을 테스트합니다. 여기에 이미지 설명을 입력하십시오

통합 테스트에서 시스템의 여러 모듈을 테스트합니다.

여기에 이미지 설명을 입력하십시오

그리고 이것은 단위 테스트 만 사용할 때 발생합니다 (일반적으로 두 창이 모두 작동하지만 불행히도 함께 작동하지 않습니다).

여기에 이미지 설명을 입력하십시오

출처 : source1 source2


세 개의 이미지가 있지만 두 개의 소스 만 있습니다.
gerrit

1
@gerrit 첫 번째 소스를 살펴보세요-두 사진이 거기에서 있습니다
Michu93

1
이 답변을 좋아합니다 👏
Dzenis H.

8

제 생각에는 "왜 중요합니까?"입니다.

단위 테스트는 당신이하고 통합 테스트는 당신이하지 않는 것이기 때문입니까? 혹은 그 반대로도? 물론, 두 가지를 모두 시도해야합니다.

단위 테스트는 빠르고, 분리 가능하고, 반복 가능하며, 자체 검증 및 적시에 수행되어야하고 통합 테스트가 아니어야합니까? 물론 모든 테스트가 이러한 테스트가 아니어야합니다.

단위 테스트에서 모의를 사용하지만 통합 테스트에서 모의를 사용하지 않기 때문입니까? 당연히 아니지. 이것은 유용한 통합 테스트를 보유하고 있다면 일부에 대한 모의를 추가 할 수 없다는 것을 의미합니다. 테스트를 "단위 테스트"로 바꾸거나 다른 프로그래머에게 넘겨서 작업해야한다는 두려움이 있습니다.

단위 테스트는 하나의 단위를 테스트하고 통합 테스트는 여러 단위를 테스트하기 때문입니까? 당연히 아니지. 그게 무슨 실질적인 중요성입니까? "범위"라는 용어는 전적으로 상황에 의존하기 때문에 테스트 범위에 대한 이론적 논의는 실제로 어쨌든 세분화됩니다. 클래스 레벨에서 단위는 메소드 일 수 있습니다. 어셈블리 수준에서 장치는 클래스 일 수 있으며 서비스 수준에서 장치는 구성 요소 일 수 있습니다. 그리고 클래스조차 다른 클래스를 사용하므로 단위는 무엇입니까?

중요하지 않습니다.

테스트는 중요합니다. 첫 번째는 중요합니다. 정의에 대해 머리카락을 나누는 것은 초보자에게만 테스트를 혼란스럽게하는 시간 낭비입니다.


5
-1 정의는 사람들이 의미하는 바를 항상 설명하지 않고 동일한 용어를 사용할 수있게하며 공동 작업에 필수적입니다. 따라서 두 개념의 차이점을 이해하는 것이 필수적입니다.
CharlesB

@CharlesB가 언급했듯이 매번 설명하거나 모든 사람들이 혼란을 일으키는 다른 정의를 찾을 필요가 없습니다. 테스트는 다르게 작성되고 다르게 실행되지만 차이점을 정의하려고해서 두 가지를 모두 수행해서는 안된다는 의미는 아닙니다.
Shane

대답의 결론은 극단적 일 수 있지만 대부분의 요점은 상당히 유효합니다. 단위 테스트와 통합 테스트 단위를 제외하고 대부분 동일 하며, 그 사이에 선을 어디에 그려야하는지 명확하지 않습니다.
Lutz Prechelt

전문적인 환경에서 공용 언어를 만들 때는 도움이되지 않습니다. 대부분 당신이 옳지 만 그다지 중요하지는 않습니다. 공통 언어가 없으면 팀 사이에 오해와 혼란이 생길 ​​것입니다. 최선의 선택은 팀이 용어와 정의에 동의하도록하는 것입니다.
user924272

4

class1에 대한 단위 테스트가 class1의 기능을 테스트하고 class2에 대한 단위 테스트가 기능을 테스트하고 데이터베이스에 충돌하지 않는 한 여전히 두 개의 상호 작용 클래스를 단위 테스트라고 부릅니다.

내 스택의 대부분을 실행하고 심지어 데이터베이스에 도달 할 때 테스트를 통합 테스트라고합니다.

TDD 토론이 때로는 너무 순수하다고 생각하기 때문에이 질문이 정말 마음에 듭니다. 그리고 구체적인 예를 보는 것이 좋습니다.


4

나는 똑같이-모든 단위 테스트라고 부릅니다. 그러나 어떤 시점에서 나는 너무 많은 것을 다루는 "단위 테스트"를 가지고 있습니다. 나는 종종 이름을 "..IntegrationTest"로 바꿉니다. 단지 이름 만 변경하면됩니다.

"원자 테스트"(하나의 작은 클래스 또는 방법 테스트)에서 단위 테스트 (클래스 레벨) 및 통합 테스트에 이르기까지 계속되고 기능 테스트 (일반적으로 위에서 아래로 더 많은 내용을 다루고 있음)가 있다고 생각합니다. -깨끗한 컷오프가없는 것 같습니다.

테스트가 데이터를 설정하고 데이터베이스 / 파일 등을로드하는 경우 통합 테스트에 더 가깝습니다 (통합 테스트는 모의와 실제 클래스를 적게 사용하지만 일부를 모의 할 수 없다는 것을 의미하지는 않습니다) 시스템).


4

단위 테스트 는 소스 코드의 개별 단위가 올바르게 작동하는지 확인하는 테스트 방법입니다.

통합 테스트 는 개별 소프트웨어 모듈이 그룹으로 결합 및 테스트되는 소프트웨어 테스트 단계입니다.

Wikipedia 는 단위를 어플리케이션에서 테스트 할 수있는 가장 작은 부분으로 정의합니다. Java / C #에서는 메소드입니다. 그러나 당신의 Word and Sentence 클래스의 예에서 나는 문장 클래스 를 테스트하기 위해 모의 단어 클래스 를 사용하는 것이 과도하다는 것을 알기 때문에 아마도 문장 테스트를 작성했을 것입니다 . 따라서 문장은 내 단위가 될 것이고 단어는 해당 단위의 구현 세부 사항입니다.


4

통합 테스트 : 데이터베이스 지속성이 테스트되었습니다.
단위 테스트 : 데이터베이스 액세스가 조롱됩니다. 코드 방법이 테스트됩니다.


3

단위 테스트는 원하는 경우 작업 단위 또는 코드 블록에 대해 테스트하는 것입니다. 일반적으로 단일 개발자가 수행합니다.

통합 테스트는 개발자가 코드를 소스 제어 저장소에 커밋 할 때 통합 서버에서 수행하는 테스트를 말합니다. 크루즈 컨트롤과 같은 유틸리티로 통합 테스트를 수행 할 수 있습니다.

따라서 단위 테스트를 수행하여 빌드 한 작업 단위가 작동하는지 검증 한 다음 통합 테스트는 저장소에 추가 한 항목이 다른 것을 위반하지 않았는지 검증합니다.


2

나는 화이트 박스 테스트 클래스를 테스트하는 단위 테스트를 호출합니다. 클래스에 필요한 모든 종속성은 가짜 (모의)로 대체됩니다.

통합 테스트는 여러 클래스와 해당 상호 작용이 동시에 테스트되는 테스트입니다. 이 경우 일부 종속성 만 위조 / 조롱됩니다.

의존성 중 하나가 실제 (예 : 위조되지 않은) (예 : IFormsAuthentication)가 아니면 컨트롤러의 통합 테스트를 호출하지 않습니다.

두 가지 유형의 테스트를 분리하면 다른 수준에서 시스템을 테스트하는 데 유용합니다. 또한 통합 테스트는 오래 지속되는 경향이 있으며 단위 테스트는 빠르다. 실행 속도 차이는 서로 다르게 실행된다는 의미입니다. 우리의 개발 프로세스에서, 단위 테스트는 체크인시 실행되며 (매우 빠릅니다) 통합 테스트는 하루에 한 번 / 두 번 실행됩니다. 가능한 한 자주 통합 테스트를 시도하고 실행하지만 일반적으로 데이터베이스에 충돌하거나 파일에 쓰거나 rpc 및 기타를 느리게 만듭니다.

이는 또 다른 중요한 점을 제기합니다. 단위 테스트는 IO (예 : 디스크, 네트워크, db)에 도달하지 않아야합니다. 그렇지 않으면 그들은 많이 느려집니다. 이러한 IO 종속성을 설계하는 데 약간의 노력이 필요합니다. "단위 테스트는 빨라야합니다"규칙에 충실했음을 인정할 수는 없지만 훨씬 큰 시스템의 이점은 매우 빠르게 나타납니다. .


2

유추에 대한 간단한 설명

위의 예제는 매우 잘 수행되므로 반복 할 필요가 없습니다. 따라서 이해를 돕기 위해 예제를 사용하는 데 중점을 둘 것입니다.

통합 테스트

통합 테스트는 모든 것이 함께 작동하는지 확인합니다. 시계에서 함께 작동하는 일련의 톱니가 있다고 상상해보십시오. 통합 테스트는 다음과 같습니다. 시계가 정확한 시간을 알려줍니까? 여전히 3 일 후에도 정확한 시간을 알려주고 있습니까?

전체 조각이 작동하는지 여부 만 알려줍니다. 실패하면 실패한 위치를 정확하게 알려주지 않습니다.

단위 테스트

이들은 실제로 특정 유형의 테스트입니다. 그들은 하나의 특정 일이 작동하는지 또는 실패하는지 알려줍니다. 이 유형의 테스트의 핵심은 다른 모든 것이 잘 작동한다고 가정하면서 하나의 특정 항목 만 테스트한다는 것입니다. 이것이 핵심입니다.

예 : 예를 사용하여이 점을 자세히 설명하겠습니다.

  • 자동차를 예로 들어 봅시다.
  • 자동차의 통합 테스트 : 예를 들어 자동차가 Woop Woop로 돌아오고 돌아 옵니까? 이 작업을 수행하면 자동차가 전체 관점에서 작동한다고 안전하게 말할 수 있습니다. 통합 테스트입니다. 그것이 실패한다면 당신은 그것이 실제로 어디에서 실패하고 있는지 전혀 모른다 : 그것이 라디에이터, 변속기, 엔진 또는 기화기인가? 당신은 모른다. 무엇이든 될 수 있습니다.
  • 자동차의 단위 테스트 : 엔진이 작동하고 있습니까? 이 테스트는 자동차의 다른 모든 것이 제대로 작동한다고 가정합니다. 이러한 특정 단위 테스트에 실패하면 엔진에 문제가 있다고 확신 할 수 있으므로 문제를 신속하게 격리하고 해결할 수 있습니다.

스텁 사용

  • 자동차 통합 테스트에 실패했다고 가정하십시오. 에 추카로 성공적으로 운전하지 않습니다. 문제는 어디에 있습니까?

  • 이제 엔진이 특수 연료 분사 시스템을 사용하고이 엔진 유닛 테스트도 실패했다고 가정합니다. 다시 말해, 통합 테스트와 엔진 유닛 테스트가 모두 실패했습니다. 그렇다면 문제는 어디에 있습니까? (10 초 동안 답을 얻으십시오.)

  • 엔진 또는 연료 분사 시스템에 문제가 있습니까?

여기서 문제가 보입니까? 정확히 무엇이 실패하는지 모릅니다. 서로 다른 외부 종속성을 사용하는 경우 이러한 10 가지 중 하나가 모두 문제를 일으킬 수 있으며 시작 위치를 알 수 없습니다. 이것이 단위 테스트가 스텁을 사용하여 다른 모든 것이 잘 작동한다고 가정하는 이유입니다.


1

이 질문은 조금 학문적이지 않습니까? ;-) 나의 견해 : 나에게 통합 테스트는 10 개 중 2 개의 파트가 함께 진행되는 경우가 아니라 전체 파트의 테스트이다. 우리의 통합 테스트는 마스터 빌드 (40 프로젝트 포함)가 성공하는지 보여줍니다. 프로젝트에는 수많은 단위 테스트가 있습니다. 나를 위해 단위 테스트와 관련하여 가장 중요한 것은 하나의 단위 테스트가 다른 단위 테스트에 의존해서는 안된다는 것입니다. 그래서 나에게 위에서 설명한 두 가지 테스트는 독립적 인 경우 단위 테스트입니다. 통합 테스트의 경우 이것은 중요하지 않아도됩니다.


1

이 테스트는 이제이 두 클래스의 통합을 테스트하기 때문에 본질적으로 통합 테스트가 되었습니까? 아니면 2 개의 수업에 걸친 단위 테스트입니까?

나는 그렇다고 생각합니다. 2 개의 클래스에 걸친 단위 테스트는 통합 테스트가되었습니다.

MockWord 클래스를 모의 구현하여 Sentence 클래스를 테스트하면 피할 수 있습니다. MockWord 클래스는 시스템의 해당 부분이 다른 개발자가 구현할 수있을 정도로 큰 경우에 중요합니다. 이 경우 Word 만 단독으로 테스트하고 MockWord를 사용하여 Sentence를 단위로 테스트 한 다음 Sentence를 Word와 통합 테스트합니다.

실제 차이는 다음과 같습니다. 1) 1,000,000 개의 요소 배열은 단위 테스트가 쉽고 잘 작동합니다. 2) BubbleSort는 10 개의 요소로 구성된 모의 배열에서 쉽게 단위 테스트를 거쳤으며 제대로 작동합니다. 3) 통합 테스트에 따르면 무언가가 좋지 않은 것으로 나타났습니다.

이 부분들이 한 사람에 의해 개발된다면, 개발자가 이미 실제 배열을 가지고 있고 모의 구현이 필요하지 않기 때문에 BubbleSoft를 단위 테스트하는 동안 문제가 발생할 가능성이 높습니다.


1

또한 단위 테스트와 통합 테스트는 모두 예를 들어 JUnit을 사용하여 자동화되고 작성 될 수 있음을 기억해야합니다. JUnit 통합 테스트에서 org.junit.Assume클래스를 사용하여 환경 요소 (예 : 데이터베이스 연결) 또는 기타 조건의 가용성을 테스트 할 수 있습니다.


0

TDD 순수 주의자 인 경우 프로덕션 코드를 작성하기 전에 테스트를 작성하십시오. 물론 테스트는 컴파일되지 않으므로 먼저 테스트를 컴파일 한 다음 테스트를 통과해야합니다.

단위 테스트로는이 작업을 수행 할 수 있지만 통합 또는 승인 테스트로는 수행 할 수 없습니다. 통합 테스트를 시도한 후에는 완료 할 때까지 컴파일되지 않습니다!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.