소프트웨어 테스트 원칙과 유형

단위 테스트를 하는 이유

단위 테스트의 핵심 목표는 애플리케이션이 예상대로 작동하는지 확인하고 사전에 버그를 찾아내는 것.

기능 테스트로도 작동을 확인하고 버그를 찾을 수 있지만, 단위 테스트를 수행했을 때 다음과 같은 장점이 있다.

 

- 기능 테스트만 수행했을 때보다 테스트 커버리지를 높일 수 있다.

: 단위 테스트는 기능 테스트로는 수행하기 어렵거나 불가능한 오류 조건에 대해서도 쉽게 테스트 할 수 있다.

 

- 팀 생산성이 향상된다.

: 단위 테스트를 활용하면 다른 컴포넌트가 준비될 때까지 기다리지 않고 질적으로 우수한 코드를 전달 할 수 있다.

반면 기능 테스트는 테스트를 실행 하기 전에 전체 애플리케이션 혹은 상당 부분이 준비되어 있어야한다.

 

- 회귀를 사전에 발견하여 디버깅 작업을 줄일 수 있다.

: 단위 테스트 묶음을 사용하면 어디에 문제가 있는지 알 수 있고 애플리케이션을 일일히 디버깅할 필요가 줄어든다.

기능테스트는 '어디엔가' 버그가 있다는 사실을 알려주지만, 단위 테스트는 특정 메서드가 어떤 이유로 실패했는지 구체적으로 알려준다.

 

- 소스를 리팩터링하거나 변경할 때 개발자에게 확신을 준다.

: 단위 테스트가 없으면 리팩터링을 정당화하기 어렵다. 소스를 고치는 일에는 항상 오류를 만들 위험이 내포되어 있기 때문이다. 이럴 때 단위 테스트가 있다면 리팩터링에 대한 확신을 주고 안전망을 제공해 줄 것이다.

 

- 애플리케이션 기능 구현에 도움을 준다.

: 단위 테스트는 테스트 중인 API를 유연하게 만들고 격리된 상태에서 테스트가 가능하게끔 만들어준다.

테스트 메서드 하나가 너무 많은 기능을 테스트하고 있을 수 있다. 격리된 상태에서 테스트가 기능을 검증하지 못한다는건 테스트 대상 코드가 충분히 유연하지 못하며 리팩토링이 필요하다는 의미다.

 

- 코드의 예상 동작을 문서화할 수 있다.

: 단위 테스트는 그 자체로 API 사용 예제가 된다. 테스트를 수행하기만 해도 유스케이스를 명확하게 알 수 있고 각 테스트를 실행할 때마다 구체적으로 어떤 일이 일어날지 알 수 있기 때문이다.

 

- 코드 커버리지를 비롯해 다양한 지표를 측정하게 해 준다.

: 단위 테스트는 라인별로 테스트가 실행 되었는지 되지 않았는지 보여주는 코드 커버리지 지표를 제공한다.

또한 도구를 사용하여 진행한 빌드에서 다음 빌드까지 테스트 통과/실패의 진행 상황도 추적할 수 있다.

 

소프트웨어 테스트 유형

소프트웨어 테스트는 범위로 분류 했을 때 다음과 같이 네 가지로 분류된다.

인수 테스트 > 시스템 테스트 > 통합 테스트 > 단위 테스트

 

테스트 범위가 클수록 소프트웨어 테스트는 조금 더 기능적이 되며, 테스트를 실행할 때 더 많은 제반 사항을 필요로한다.

 

- 단위 테스트

: 단위 테스트는 소스 코드의 개별 단위(메서드나 클래스)를 테스트하여 해당 코드를 사용할 수 있는지를 결정하는 소프트웨어 테스트 기법이다. 개별 단위를 격리하여 테스트하는 것이 중요하다.

 

- 통합 테스트

: 서로 다른 개별 작업 단위가 하나의 작업 흐름으로 합쳐지면 어떻게 될까? 통합 테스트는 이처럼 대상 환경에서 실행 가능한 컴포넌트 간의 상호작용을 테스트하는 것이다.

 

- 시스템 테스트

: 시스템 테스트는 시스템이 구체화된 요구 사항을 만족하는지 평가하기 위해 완전한 통합 환경에서 수행하는 테스트를 말한다. 이 테스트의 목표는 통합되어 있는 단위 간의 불일치를 찾아내는 것이다. 여기서 테스트 더블이나 모의 객체를 활용하여 의존하는 컴포넌트를 테스트에 통합하는 것이 불가능하거나 지금 당장 사용할 수 없을때 유용하게 테스트 할 수 있다.

 

- 인수 테스트

: 최종 수준의 테스트 단계로 애플리케이션이 고객이나 이해관계자가 정의한 목표를 달성하는지 확인하기 위한 테스트이다. 애플리케이션이 비즈니스 목표를 달성하고 기획한 작업을 제대로 하고 있는지와 같은 필수적인 질문에 답할 수 있다.

Given, When, Then 같은 키워드를 사용하여 표현할 수 있다.

 

블랙박스 테스트와 화이트박스 테스트

- 블랙박스 테스트

: 시스템의 내부 상태나 동작에 대한 지식이 없을 때 수행하는 테스트이다. 정확성을 검증하기 위해 외부적인 시스템 인터페이스를 사용한다. 오로지 시스템 기능적 명세로만 테스트하여 QA엔지니어, 개발자, 고객 등 누구나 시스템을 테스트 할 수 있다.

 

- 화이트박스 테스트

: 유리상자 테스트라고도 부르며, 구현에 관한 해박한 지식을 바탕으로 테스트를 만들고 테스트 프로세스를 진행한다.

컴포넌트 구현을 이해하는 것 외에도 테스트 프로세스가 다른 구성요소와 상호작용하는 방식을 알아야하므로 개발자가 테스트 하는 것이 적격이다. 테스트에 GUI가 필요없어 프로젝트 초기단계에 구현할 수 있고, 외부 사용자가 알 수 없는 다양한 실행 경로를 커버할 수 있다.

 

- 장단점 비교

상황에 따라 사용자 중심 테스트가 필요할 수도 있고, 시스템의 세부 구현을 테스트해야 할 수도 있다.

두 가지 방식을 함께 고려하는 것이 가장 합리적이다.

	장점	단점
블랙박스 테스트	- 사용자 중심적이며 설계 명세와 다른부분이 무엇인지 바로 알 수 있다. - 테스터가 비개발자여도 상관없다. - 개발자와 독립적으로 수행할 수 있다.	- 입력할 수 있는 경우의 수가 제한적이다. - 커버되지 않은 실행 경로가 많을 수 있다. - 테스트가 중복될 수 있다. 세부 정보가 없다는 것은 동일한 실행 경로를 여러번 커버할 수 있다는 것을 의미한다.
화이트박스 테스트	- 프로젝트 초기부터 테스트를 구현할 수 있다. - GUI가 필요하지 않다. - 개발자가 제어하므로 다양한 실행경로를 커버할 수 있다.	- 프로그래밍 지식이 있는 사람만 테스트를 구현할 수 있다. - 구현을 변경하려면 테스트를 다시 작성해야한다. - 테스트와 구현이 밀접하게 결합되어 있다.