(왜) 단위 테스트가 종속성을 테스트하지 않는 것이 중요합니까?

나는 자동화 된 테스트의 가치를 이해하고 문제가 잘 구체화되어있는 곳이면 어디에서나 좋은 테스트 사례를 만들 수있을 때 사용합니다. 그러나 여기 및 StackOverflow의 일부 사람들 은 종속 장치가 아닌 단위 테스트 만 강조 합니다. 나는 이점을 보지 못했다.

테스트 종속성을 피하기 위해 조롱 / 스터 빙하면 테스트가 복잡해집니다. 조롱을 지원하기 위해 프로덕션 코드에 인공 유연성 / 감 결합 요구 사항을 추가합니다. (나는 이것이 좋은 디자인을 장려한다고 말하는 사람에 동의하지 않는다. 추가 코드 작성, 의존성 주입 프레임 워크와 같은 것을 도입하거나 코드베이스에 복잡성을 추가하여 실제 사용 사례없이 더 유연하고 플러그 가능 / 확장 가능 / 분리 된 것을 만드는 것은 과도하게 엔지니어링되지 않는다. 좋은 디자인.)

둘째, 의존성을 테스트한다는 것은 모든 곳에서 사용되는 중요한 저수준 코드가 테스트를 작성한 사람이 아닌 다른 입력으로 테스트된다는 것을 의미합니다. 하위 수준의 기능을 모방하지 않고 높은 수준의 기능에 대한 단위 테스트를 실행하여 하위 수준의 기능에서 많은 버그를 발견했습니다. 이상적으로는 하위 수준 기능에 대한 단위 테스트에서 발견되었지만 누락 된 경우는 항상 발생합니다.

이것의 반대편은 무엇입니까? 단위 테스트가 종속성을 테스트하지 않는 것이 정말로 중요합니까? 그렇다면 왜 그렇습니까?

편집 : 데이터베이스, 네트워크, 웹 서비스 등과 같은 외부 종속성 을 조롱하는 것의 가치를 이해할 수 있습니다 (Anna Lear에게 감사드립니다). 내부 종속성 , 즉 다른 클래스, 정적 함수 등을 언급하고 있습니다 . 직접적인 외부 의존성이 없습니다.

정의의 문제입니다. 종속성이있는 테스트는 단위 테스트가 아닌 통합 테스트입니다. 통합 테스트 스위트도 있어야합니다. 차이점은 통합 테스트 스위트가 다른 테스트 프레임 워크에서 실행될 수 있으며 시간이 오래 걸리기 때문에 빌드의 일부가 아닐 수 있다는 것입니다.

우리 제품의 경우 : 단위 테스트는 각 빌드마다 실행되며 몇 초가 걸립니다. 통합 테스트의 일부는 10 분 동안 체크인 할 때마다 실행됩니다. 전체 통합 제품군은 매일 밤 실행되며 4 시간이 걸립니다.

모든 의존성을 가지고 테스트하는 것은 여전히 ​​중요하지만 Jeffrey Faust가 말한 것처럼 통합 테스트 영역에 있습니다.

단위 테스트의 가장 중요한 측면 중 하나는 테스트를 신뢰할 수있게 만드는 것입니다. 통과 테스트가 실제로 문제가 없다는 것을 의미하지 않고 테스트 실패가 실제로 프로덕션 코드의 문제를 의미한다고 믿을 수 없다면 테스트는 그다지 유용하지 않습니다.

테스트를 신뢰할 수있게하려면 몇 가지 작업을 수행해야하지만이 답변에 대해 하나만 집중하겠습니다. 코드를 체크인하기 전에 모든 개발자가 쉽게 실행할 수 있도록 실행하기 쉬운 지 확인해야합니다. "쉽게 실행"은 테스트가 빠르게 실행 되고 테스트를 신속하게 수행 할 수 있도록 구성 또는 설정이 필요하지 않음을 의미합니다 . 이상적으로는 누구나 최신 버전의 코드를 확인하고 테스트를 즉시 실행하여 통과하는 것을 볼 수 있어야합니다.

다른 것 (파일 시스템, 데이터베이스, 웹 서비스 등)에 대한 의존성을 제거하면 구성이 필요하지 않으며, "아, 내가 실패했기 때문에 테스트에 실패했습니다. 네트워크 공유가 설정되어 있지 않습니다. 아, 나중에 실행하겠습니다. "

일부 데이터로 수행 한 작업을 테스트하려는 경우 해당 비즈니스 로직 코드에 대한 단위 테스트는 해당 데이터를 얻는 방법에 신경 쓰지 않아야 합니다. 데이터베이스와 같은 지원 항목에 의존하지 않고 응용 프로그램의 핵심 논리를 테스트 할 수 있다는 것은 대단합니다. 하지 않으면 빠진 것입니다.

추신 : 나는 테스트 가능성이라는 이름으로 과도하게 엔지니어링 할 수 있다고 덧붙여 야합니다. 애플리케이션을 시험 구동하면이를 완화 할 수 있습니다. 그러나 어쨌든 접근 방식의 구현이 잘못되어 접근 방식의 유효성이 떨어지지는 않습니다. "내가 왜 이러는 걸까?"라는 질문을 계속하지 않으면 어떤 것도 잘못 사용하고 지나칠 수 있습니다. 개발하는 동안.

public class MyClass 
{
    private SomeClass someClass;
    public MyClass()
    {
        someClass = new SomeClass();
    }

    // use someClass in some way
}

나는 일반적으로 어떻게 SomeClass만들어 지는 상관하지 않습니다 . 그냥 사용하고 싶습니다. SomeClass가 변경되어 생성자에 매개 변수가 필요한 경우 내 문제가 아닙니다. 이를 수용하기 위해 MyClass를 변경할 필요는 없습니다.

이제는 디자인 부분 만 다루고 있습니다. 단위 테스트에 관한 한, 나는 또한 다른 수업으로부터 자신을 보호하고 싶습니다. MyClass를 테스트하는 경우 외부 종속성이 없으며 SomeClass가 데이터베이스 연결이나 다른 외부 링크를 도입하지 않았다는 사실을 알고 싶습니다.

그러나 더 큰 문제는 내 메소드의 일부 결과가 SomeClass의 일부 메소드의 출력에 의존한다는 것도 알고 있다는 것입니다. SomeClass를 조롱 / 스터 빙하지 않으면 요구에 따라 입력을 변경할 수있는 방법이 없을 수 있습니다. 운이 좋으면 SomeClass의 올바른 응답을 트리거하는 방식으로 테스트 내 환경을 작성할 수 있지만 그렇게하면 테스트에 복잡성이 생겨 부서지기 쉽습니다.

생성자에서 SomeClass의 인스턴스를 허용하도록 MyClass를 다시 작성하면 (모의 프레임 워크 또는 수동 모의를 통해) 원하는 값을 반환하는 SomeClass의 가짜 인스턴스를 만들 수 있습니다. 나는 일반적으로하지 않습니다 이 이 경우에 인터페이스를 소개합니다. 그렇게 할 것인지 아닌지는 여러 가지면에서 여러분이 선택한 언어에 의해 지시 될 수있는 개인적인 선택입니다 (예를 들어 C #에서는 인터페이스가 더 많지만 루비에서는 반드시 필요하지 않습니다).

단위 대 통합 테스트 문제 외에도 다음을 고려하십시오.

클래스 위젯은 Thingamajig 및 WhatsIt 클래스에 종속됩니다.

위젯에 대한 단위 테스트가 실패합니다.

어느 수업에 문제가 있습니까?

"디버거를 작동 시키십시오"또는 "찾을 때까지 코드를 읽습니다"라고 대답 한 경우 종속성이 아닌 유닛 만 테스트하는 것이 중요하다는 것을 이해합니다.

프로그래밍이 요리와 같다고 상상해보십시오. 그런 다음 단위 테스트는 재료가 신선하고 맛있는 지 확인하는 것과 같습니다. 통합 테스트는 식사가 맛있는 지 확인하는 것과 같습니다.

궁극적으로 식사가 맛 있거나 시스템이 작동하는지 확인하는 것이 가장 중요한 목표입니다. 그러나 당신의 재료, 즉 단위, 작동한다면, 당신은 더 싼 방법을 찾을 것입니다.

실제로, 장치 / 방법이 작동한다고 보장 할 수 있다면 작동하는 시스템이있을 가능성이 높습니다. 나는 "확실한"과는 반대로 "보다 가능성이 높다"고 강조합니다. 요리 한 음식을 맛보고 최종 제품이 좋다고 말하는 사람이 필요 하듯이 통합 테스트가 여전히 필요합니다. 신선한 재료로 쉽게 갈 수 있습니다.

장치를 완전히 분리하여 테스트하면 가능한 모든 데이터 및 상황을 제출할 수 있습니다. 나머지와 분리되어 있으므로 테스트 할 장치에 직접적인 영향을 미치지 않는 변형을 무시할 수 있습니다. 결과적으로 테스트의 복잡성이 크게 줄어 듭니다.

다양한 수준의 종속성을 통합하여 테스트하면 단위 테스트에서 테스트되지 않은 특정 시나리오를 테스트 할 수 있습니다.

둘 다 중요합니다. 단위 테스트 만하면 구성 요소를 통합 할 때 발생하는보다 복잡한 미묘한 오류가 발생합니다. 통합 테스트 만하면 시스템의 개별 부품이 테스트되지 않았다는 확신없이 시스템을 테스트 할 수 있습니다. 통합 테스트를 수행하는 것만으로도 더 나은 완전한 테스트를 달성 할 수 있다고 생각하는 것은 엔트리 조합의 수를 추가할수록 더 많은 구성 요소가 매우 빠르게 증가하고 (계수 적) 충분한 커버리지로 테스트를 작성하는 것은 매우 빠르게 불가능하므로 거의 불가능합니다.

간단히 말해, 나는 거의 모든 프로젝트에서 일반적으로 사용하는 세 가지 레벨의 "단위 테스트"를 사용합니다.

• 단일 구성 요소의 지옥을 테스트하기 위해 모의 또는 스터 빙 종속성으로 격리 된 단위 테스트. 이상적으로는 완전한 커버리지를 시도 할 것입니다.
• 보다 미묘한 오류를 테스트하기위한 통합 테스트. 제한 사례와 일반적인 조건을 보여주는 신중하게 제작 된 현장 점검. 완전한 적용 범위가 불가능한 경우가 많으며, 시스템 장애를 일으키는 원인에 중점을 둡니다.
• 시스템에 다양한 실제 데이터를 주입하고, 가능한 경우 데이터를 계측하고, 출력이 사양 및 비즈니스 규칙을 준수하는지 확인하기위한 사양 테스트.

의존성 주입은 시스템에 복잡성을 추가하지 않고도 단위 테스트를 위해 구성 요소를 매우 쉽게 분리 할 수 ​​있으므로이를 달성하는 매우 효율적인 방법 중 하나입니다. 비즈니스 시나리오는 주입 메커니즘 사용을 보증하지는 않지만 테스트 시나리오는 거의 사용됩니다. 이것은 나를 위해 필수 불가결 한 것으로 충분합니다. 이들을 사용하여 부분 통합 테스트를 통해 독립적으로 다른 레벨의 추상화를 테스트 할 수 있습니다.

이것의 반대편은 무엇입니까? 단위 테스트가 종속성을 테스트하지 않는 것이 정말로 중요합니까? 그렇다면 왜 그렇습니까?

단위. 단수를 의미합니다.

두 가지를 테스트한다는 것은 두 가지 와 모든 기능적 종속성 이 있음을 의미합니다 .

세 번째 항목을 추가하면 테스트의 기능적 종속성이 선형 적으로 증가합니다. 사물 사이의 상호 연결은 사물 수보다 더 빠르게 커집니다.

테스트중인 n 개의 항목 중에서 n (n-1) / 2의 잠재적 종속성이 있습니다.

그게 큰 이유입니다.

단순성은 가치가 있습니다.

재귀를 처음 배운 방법을 기억하십니까? 내 교수는 "x를 수행하는 방법이 있다고 가정합니다"라고 말합니다 (예 : 피보나치 문제를 x로 해결). "x를 해결하려면 x-1과 x-2에 대해 해당 메소드를 호출해야합니다." 같은 점에서, 의존성을 제거하는 것은 그들이 존재하는 척하고 현재 유닛이해야 할 일을 수행하는지 테스트 할 수있게합니다. 물론 의존성을 엄격하게 테스트한다고 가정합니다.

이것은 본질적으로 직장에서의 SRP입니다. 심지어 검사에 대한 단일 책임에 집중하면해야 할 정신적 저글링의 양이 줄어 듭니다.

(이것은 사소한 답변입니다. 힌트를 주셔서 @TimWilliscroft에게 감사드립니다.)

다음과 같은 경우 오류를 지역화 하기가 더 쉽습니다 .

• 테스트 대상 단위와 각 종속 항목은 독립적으로 테스트됩니다.
• 테스트에 포함 된 코드에 결함이있는 경우에만 각 테스트에 실패합니다.

이것은 종이에 잘 작동합니다. 그러나 OP의 설명 (종속성에 버그가 있음)에 설명 된 것처럼 종속성을 테스트하지 않으면 결함의 위치를 ​​정확히 파악하기가 어렵습니다.

좋은 답변이 많이 있습니다. 또한 몇 가지 다른 요점을 추가합니다.

또한 단위 테스트를 통해 종속성 이 없을 때 코드를 테스트 할 수 있습니다 . 예를 들어, 귀하 또는 귀하의 팀이 다른 계층을 아직 작성하지 않았거나 다른 회사에서 제공 한 인터페이스를 기다리고있을 수 있습니다.

단위 테스트는 또한 개발자 컴퓨터 (예 : 데이터베이스, 웹 서버 등)에 완전한 환경이 필요하지 않음을 의미합니다. 나는 강한 모든 개발자가 추천 할 몇 가지 이유가 프로덕션 환경을 모방 할 수없는 경우가 생식 버그 위해서입니다 삭감 그러나, 이러한 환경을 등 그러나, 다음 단위 테스트는 적어도 유 몇 가지 수준을 제공합니다 더 큰 테스트 시스템으로 들어가기 전에 코드에 대한 확신.

디자인 측면 : 작은 프로젝트라도 코드를 테스트 할 수있는 이점이 있다고 생각합니다. Guice (간단한 팩토리 클래스가 종종 할 것)와 같은 것을 소개 할 필요는 없지만 프로그래밍 로직 결과에서 구성 프로세스를 분리합니다.

• 인터페이스를 통해 모든 클래스의 종속성을 명확하게 문서화합니다 (팀을 처음 접하는 사람들에게 매우 도움이 됨)
• 클래스가 훨씬 명확하고 쉽게 유지 관리가 가능합니다 (한 번 추악한 객체 그래프 생성을 별도의 클래스에 넣음)
• 느슨한 커플 링 (변경이 훨씬 쉬워 짐)

어 ... 여기에 대한 답변으로 작성된 단위 및 통합 테스트에 대한 좋은 점이 있습니다!

나는 그리워 비용과 관련된 실제적인 뷰를 여기에. 즉, 매우 고립 된 / 원자 단위 테스트 (데이터베이스, 파일 시스템 등의 종속성없이 병렬로 실행할 수있는 옵션)와 (높은 수준의) 통합 테스트의 이점을 분명히 알 수 있습니다. 그러나 ... 또한 비용 (시간, 돈 등)과 위험 의 문제이기도합니다 .

내 경험에서 "테스트하는 방법" 을 생각하기 전에 훨씬 더 중요한 다른 요소가 있습니다 (예 : "무엇을 테스트할지" ) .

내 고객이 추가 쓰기 및 유지 관리 테스트 비용을 암시 적으로 지불합니까? 보다 테스트 중심의 접근 방식 (코드를 작성하기 전에 먼저 테스트를 작성)이 내 환경 (코드 오류 위험 / 비용 분석, 사람, 설계 사양, 테스트 환경 설정)에서 실제로 비용 효율적입니까? 코드는 항상 버그가 있지만 테스트를 프로덕션 용도 (최악의 경우)로 옮기는 것이 더 비용 효율적일 수 있습니까?

또한 코드 품질 (표준)이 무엇인지, 프레임 워크, IDE, 디자인 원칙 등 여러분과 팀이 따라야하는 경험과 그 경험에 따라 달라집니다. 잘 작성되고, 이해하기 쉽고, 충분히 문서화되어 있고 (이상적으로 자체 문서화) 모듈 식 코드는 반대보다 버그가 적습니다. 따라서 광범위한 테스트를위한 실제 "필요", 압력 또는 전체 유지 보수 / 버그 수정 비용 / 위험은 높지 않을 수 있습니다.

우리 팀의 동료가 제안한 극한까지 살펴 보자. 순수한 Java EE 모델 계층 코드를 데이터베이스 내의 모든 클래스와 모의 클래스에 대해 원하는 100 % 적용 범위로 단위 테스트를 시도해야한다. 또는 통합 테스트를 원하는 관리자는 모든 실제 사용 사례 및 웹 UI 워크 플로의 100 %를 적용하여 사용 사례가 실패 할 위험이 없기 때문입니다. 그러나 우리는 약 100 만 유로의 예산을 가지고 있으며, 모든 것을 코딩 할 계획이 있습니다. 잠재적 인 앱 버그가 사람이나 회사에 큰 위험이되지 않는 고객 환경. 우리의 앱은 내부적으로 (일부) 중요한 단위 테스트, 통합 테스트, 설계된 테스트 계획을 통한 주요 고객 테스트, 테스트 단계 등으로 테스트됩니다. 우리는 일부 원자력 공장이나 제약 생산을위한 앱을 개발하지 않습니다!

나는 가능한 경우 테스트를 작성하고 코드를 단위 테스트하는 동안 개발하려고합니다. 그러나 나는 종종 하향식 접근 방식 (통합 테스트)에서이 작업을 수행하고 중요한 테스트 (종종 모델 계층에서)를 위해 "앱 계층 잘라 내기"를 수행 할 수있는 좋은 점을 찾으려고 노력합니다. ( "레이어"에 대해 종종 많기 때문에)

또한 단위 및 통합 테스트 코드는 시간, 비용, 유지 관리, 코딩 등에 부정적인 영향을 미치지 않습니다. 시원하고 적용해야하지만 5 년 동안 개발 된 많은 테스트를 시작하거나 5 년 동안 수행 한 후주의가 필요합니다. 암호.

따라서 실제로 는 신뢰 또는 비용 / 위험 / 혜택 평가에 크게 의존 한다고 말하고 싶습니다. 실제 생활에서와 같이 100 % 안전 메커니즘으로 뛰어 다니고 싶지 않으며 달리고 싶지 않습니다.

아이는 어딘가에 올라가서 넘어져서 다칠 수 있습니다. 잘못된 연료를 채워서 차가 작동을 멈출 수 있습니다 (잘못된 입력 :). 3 년 후에 시간 단추가 작동을 멈 추면 토스트가 연소 될 수 있습니다. 그러나 나는 절대로 고속도로를 운전하고 분리 된 스티어링 휠을 손에 쥐고 싶지 않습니다. :)