블랙 박스 단위 테스트 란 무엇입니까?

최근에 석사 프로그램을위한 소프트웨어 엔지니어링 과정에 대한 최종 시험을 보았으며 시험 문제 중 하나는 다음과 같습니다.

Unit Testing is considered:
a. White-box Testing
b. Black-box Testing
c. Either

7 년간의 소프트웨어 개발 경험에서 단위 테스트는 항상 화이트 박스 방식을 사용했습니다. 테스터는 테스트를 작성하는 동안 항상 유닛의 구현에 대해 완전히 알고있었습니다. 블랙 박스 테스트는 항상 통합, 시스템 및 승인 테스트 형식으로 이루어졌습니다.

그러나, 교수에 따르면, 시험에 대한 정답은 단위 테스트가 화이트 또는 블랙 박스 테스트 일 수 있다는 것입니다.

나는 약간의 연구를 해왔으며 많은 경우 "블랙 박스 단위 테스트"가 코드가 작성되기 전에 단위 테스트가 작성되는 테스트 우선 접근 방식을 설명하는 데 사용됩니다. 그러나 내 의견으로는 이것은 여전히 ​​화이트 박스 테스트입니다. 구현은 아직 존재하지 않지만 테스트를 작성하는 사람은 일반적으로 소스 코드가 어떻게 구현 될 것인지에 대해 꽤 좋은 생각을 가지고 있습니다.

누군가가 블랙 박스 단위 테스트가 어떻게 작동하는지 (진정한 경우) 화이트 박스 단위 테스트와 어떻게 다른지 설명해 주시겠습니까?

교수님이 맞습니다 : 단위 테스트는 블랙 박스 또는 화이트 박스 일 수 있습니다. 차이점은 테스터가 아는 것이 아니라 테스트 사례를 생성하는 방법에 대한 것입니다.

블랙 박스 테스트에서는 구성 요소의 인터페이스와 사양 (있는 경우) 만 살펴 봅니다. 함수에 서명이 있으면 int foo(int a, int b)0, 1, 빼기 1, 여러 자리 숫자, INT_MAX, INT_MAX-1 등 흥미로운 정수를 테스트하여 몇 가지 테스트 사례를 즉시 생성 할 수 있습니다. 블랙 박스 테스트는 구현과 독립적이므로 훌륭합니다. 그러나 그들은 중요한 경우를 놓칠 수도 있습니다.

화이트 박스 테스트를 통해 구현, 즉 소스 코드를 살펴보고 테스트 사례를 생성합니다. 예를 들어, 함수에 대해 100 % 경로 적용 범위를 달성하고자 할 수 있습니다. 그런 다음 모든 경로가 사용되도록 입력 값을 선택합니다. 화이트 박스 테스트는 블랙 박스 테스트보다 훨씬 더 자신감을 가지고 코드를 철저히 연습 할 수 있기 때문에 훌륭합니다. 그러나 실제로 중요한 행동이 아니라 구현 세부 사항 만 테스트하는 것일 수 있습니다. 어떤 경우에는 분명히 시간 낭비입니다.

화이트 박스 테스트는 구현에서 파생되었으므로 나중에 작성할 수 있습니다. 블랙 박스 테스트는 디자인 / 인터페이스 / 사양에서 파생되므로 구현 전후에 작성할 수 있습니다. TDD는 블랙 박스 나 화이트 박스가 아닙니다. 모든 동작은 먼저 테스트에 의해 표현 된 다음 해당 동작에 대한 최소 코드가 구현되므로 TDD는 화이트 박스 테스트와 유사한 테스트 사례를 발생시킵니다. 그러나 정보 흐름을 볼 때 TDD 테스트는 소스 코드가 아니라 외부 요구 사항에서 파생됩니다. 따라서 TDD는 블랙 박스와 유사합니다.

테스트 주도 개발을 수행하는 경우 이론적으로 모든 단위 테스트는 블랙 박스 여야합니다. 이것이 "테스트 우선 접근"입니다. 계약 (인터페이스)을 작성하고 해당 계약에 대한 테스트를 작성한 다음 구현에 의해 계약이 이행됩니다. 따라서 테스트는 구현에 대해 아무것도 모르고 아무것도 알아야합니다.

결국, 테스트를 작성할 때 무엇을 테스트하고 있습니까? 공개 방법 / 기능.

수업에 대한 인터페이스를 작성하고 테스트를 작성한 다음 버스에 치면 병원에있는 동안 수업을하는 사람이 인터페이스에서 그렇게 할 수 있어야합니까? 그는 그것을 버리고 자신의 인터페이스와 테스트를 작성할 필요가 없습니다.

이것이 다소 차이가 나는 곳은 구현이 의존하는 것을 조롱해야 할 때이지만, 공개적으로 노출되지 않은 것을 조롱하는 상황에 처하면 실수를 저지른 다음 실수해야합니다. Dependency Injection et al . 따라서 검정이 아닌 흰색 상자 단위 테스트는 예외라고 주장합니다.

클래스의 구현은 변경되었지만 테스트는 여전히 유효해야하는 '화장실 테스트 테스트 구현이 아님'을 고려하십시오 .

그러나 코드 적용 범위를 확인해야하는 경우 (즉, 모든 조건부 경로가 구현 내에서 테스트되었는지 확인) 단위 테스트를 반드시 수행해야합니다. 경로는 구현에서 경로를 살펴 보는 것입니다.

잘 작성된 모든 단위 테스트는 본질적으로 "블랙 박스"라고 주장합니다. 테스트를 작성할 때 구현을 염두에 두어야하지만 리팩토링하면 구현이 변경 될 수 있습니다. 따라서 테스트는 구현이 아니라 기능을 테스트하기 위해 테스트 중에 퍼블릭 API 만 사용해야합니다. 구현 세부 사항은 신경 쓰지 않으므로 블랙 박스 테스트가 필요합니다.

테스트 대상 유닛의 내부 또는 개인 측면에 액세스하는 테스트를 작성하면 구현 세부 사항을 테스트하는 것입니다. 나는 화이트 박스 테스트입니다. 그러나 구현이 변경되면 쉽게 깨질 수있는 취성 테스트를 작성 중입니다. 따라서 이러한 화이트 박스 테스트는 나쁜 생각이므로 피해야합니다.

결론 : 단위 테스트로 화이트 박스 테스트를 수행하면 테스트가 제대로 구성되지 않은 것입니다. 해당 단위 테스트를 통한 백 박스 테스트 만 가능합니다. 교수님이 맞습니다. 둘 중 하나 일 수 있습니다. 그러나 잘못한 경우에만.

블랙 박스 테스트를 수행하는 단위 테스트를 작성하는 중이었습니다. 즉, 클래스에서 공개 메소드를 테스트하고 결과 메소드를 호출하는 개인 메소드에 로직을 테스트합니다.

나는 단위 테스트되는 공용 메소드로 입력을 변경하고 지원하는 개인 메소드에서 논리에 의해 결정되거나 변경되는 예상 출력을 테스트함으로써이 작업을 수행한다.

따라서 단위 테스트에서 블랙 박스 테스트 수행을 중단하는 것은 없으며 누군가가 숨겨진 지원 논리의 구현을 망칠 경우 테스트가 중단됩니다. 실제로 이것은 클래스를 위해 클래스 박스의 모든 것을 테스트하는 화이트 박스 단위보다 우수하고 효율적인 접근 방식처럼 보입니다. 저는 교수님과 함께 있습니다.