아직도 Beizer처럼 테스트할 수 있나요?
Source: Dev.to
배경 및 초기 질문
누구나 열린 공간에서 이런 질문을 들어본 적이 있을 것입니다: “그래, 그런데 네 유닛은 어느 정도 크기야?”
그리고 답은 “작아, 예를 들어… 음”이라며 비교 포인트가 사라지는 경우 말이죠.
그 사람도 JUnit, PHPUnit 혹은 다른 프레임워크를 사용합니다.
Kent Beck이 정의한 단위 테스트
Test‑Driven Development By Example (2003)에서 Kent Beck은 다음과 같이 적었습니다:
“작은 규모의 테스트(제가 ‘단위 테스트’라고 부르지만, 일반적인 단위 테스트 정의와는 다소 차이가 있습니다)로 개발을 진행할 때의 문제는, 사용자가 원하는 바를 구현했다고 생각하지만 실제로는 전혀 원하지 않는 것을 구현하게 될 위험이 있다는 점입니다.”
Beck은 두 가지 정보를 제공합니다:
- ‘단위 테스트’라는 정의는 실제 업무 현장에서 존재한다.
- 그 정의와는 무관하게 JUnit이라는 이름은 ‘그대로 쓰고 무시한다’.
Boris Beizer의 정의
국제 소프트웨어 테스트 자격 위원회(International Software Testing Qualification Board)의 저명한 회원이자 Software Testing Techniques (1983)와 Software System Testing and Quality Assurance (1984)의 저자인 Boris Beizer는 1990년 두 번째 판에서 테스트를 세 가지 유형으로 구분했습니다.
Beizer가 제시한 테스트 유형
| 유형 | 설명 |
|---|---|
| 유닛, Unit Test | 유닛은 소프트웨어에서 가장 작은 테스트 가능한 요소이며, 컴파일·조립·링크·로드가 가능하고 테스트 하네스나 드라이버에 의해 제어될 수 있습니다. 일반적으로 한 프로그래머가 작업한 수백 줄(또는 그 이하) 정도의 소스 코드로 구성됩니다. 단위 테스트는 해당 유닛이 기능 사양을 만족하지 않거나 구현 구조가 설계와 일치하지 않음을 보여주기 위해 수행됩니다. 발견된 결함은 unit bug이라고 부릅니다. |
| 컴포넌트, Component Test | 컴포넌트는 하나 이상 유닛이 통합된 집합입니다. 재귀적인 정의에 따라, 컴포넌트는 유닛 자체일 수도, 서브시스템일 수도, 전체 시스템일 수도 있습니다. 컴포넌트 테스트는 해당 컴포넌트가 기능 사양을 만족하지 않거나 구현 구조가 기술 설계와 일치하지 않음을 보여주기 위해 수행됩니다. 발견된 결함은 component bug이라고 부릅니다. |
| 통합, Integration Test | 통합은 여러 컴포넌트를 결합해 더 큰 컴포넌트를 만드는 과정입니다. 통합 테스트는 각각의 컴포넌트가 개별적으로는 정상이라도, 결합된 결과가 잘못되었거나 호환되지 않을 때 이를 확인합니다. |
| 시스템, System Test | 시스템은 ‘큰 컴포넌트’라고 할 수 있습니다. 시스템 테스트는 개별 컴포넌트에 귀속시킬 수 없는 이상 현상을 찾아냅니다. 예를 들어 컴포넌트 간 호환성 문제, 예상치 못한 상호 작용, 성능·보안·설정·시작·복구와 관련된 문제 등이 포함됩니다. |
컴포넌트 vs 통합 차이 예시
예시: 재귀적으로 호출되는 서브루틴
A가 있다고 가정합니다.
- 컴포넌트 테스트는 하위 컴포넌트 호출을 포함하지 않으므로
A의 재귀 호출 자체는 테스트되지 않습니다.- 통합 테스트는
A를 호출하고 반환값을 확인하며, 재귀 호출에 필요한 스택 등도 함께 검증합니다. 이렇게 새롭게 통합된 컴포넌트는 추가적인 테스트가 필요합니다.
정의의 영문 원문 (발췌)
“We do three distinct kinds of testing on a typical software system: unit/component testing, integration testing, and system testing. The objectives of each class are different and therefore, we can expect the mix of test methods used to differ.”
Unit, Unit Testing — A unit is the smallest testable piece of software, by which I mean that it can be compiled or assembled, linked, loaded, and put under the control of a test harness or driver. A unit is usually the work of one programmer and consists of several hundred or fewer lines of source code. Unit testing is performed to show that the unit does not satisfy its functional specification and/or that its implemented structure does not match the intended design. When such faults are revealed, we speak of a unit bug.
Component, Component Testing — A component is an integrated aggregate of one or more units. A unit is a component; a component with the subroutines it calls is also a component, etc. By this recursive definition, a component can be anything from a single unit to an entire system. Component testing is performed to show that the component does not satisfy its functional specifications and/or that its implementation structure does not match the technical design. Faults detected are called component bugs.
결론
Beizer는 유닛부터 전체 시스템에 이르는 다양한 테스트 수준을 명확하고 상세하게 분류했습니다. 현대 교육 과정에서 그의 이름이 자주 언급되지 않더라도, 그의 연구는 소프트웨어 품질을 깊이 있게 탐구하고자 하는 모든 사람에게 여전히 귀중한 참고 자료입니다. Beizer를 읽는다는 것은 ‘작은 규모의 테스트’ 함정에 빠지지 않도록 견고한 프레임워크를 갖추고, 각 통합 단계가 올바르게 검증되도록 하는 데 큰 도움이 됩니다.